-
Notifications
You must be signed in to change notification settings - Fork 821
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What about IE11 support? #902
What about IE11 support? #902
Comments
FYI there are usually ways for toolchains to transpile node_modules (e.g. override webpack exclude). That said, it is common for packages to publish multiple ES versions in the same package, with "es5", "es2016", etc. keys in package.json. |
How does one achieve this with TypeScript? I'm not sure of how to configure TS to transpile dependencies, at least not when they are shipping JS rather than TS sources. Maybe we could try to do it as part of rollup for our bundle output, but I don't think that would help our ESM output (which comes directly from TS for ease of tree-shaking.) |
@xirzec I think paul was suggesting that we as opentelemetry publish with multiple targets so that the projects which rely on us can bundle the correct target. |
That would work! ❤️ |
see #593 for background and differences in generated |
Is support for ES5 planned? |
To bump this thread again, I think for the purposes of how my team uses this, it would help greatly if |
This seems like a good tradeoff to me. There is no "real behavior" in the API to worry about anyway. The only thing I would be concerned about would be the I think compiling the API down to the lowest possible target is also a good idea because if we want any modules like db drivers or http clients to build in support for otel, they will not be able to support IE11 if the API at least does not. |
Would like to get the opinion of @Flarna on that. There is no use of the
Use of |
We used transpile to ES5 for quite a while without problems. If I took a look into the api and context-base package and it seems the difference is small:
|
The product I work on (Azure SDK) has some client libraries that want to support IE11 because they have customers that bundle for the browser and IE11 is still in their supported matrix.
Right now OT won't work as built because it is compiled with
target: "es2017"
rather thantarget: "es5"
I would love to be in a world without the need for IE11 support, but it feels bad for something as low-level as tracing to not have any support story for browsers that are still officially supported by an in-market OS.
The text was updated successfully, but these errors were encountered: