exceptionless
Feature Request: Add CJS Support
At least not without some configuration and transpiling.
I created a new AWS Lambda project (using Claudia.js). I tried to import the Exceptionless client but import statements are not supported out of the box:
SyntaxError: Cannot use import statement outside a module
So, I tried to use a require statement, but the Exceptionless client doesn't allow it:
require() of ES modules is not supported.
This makes for a rough developer experience because I now have to go hunt down the solution to making a client library work rather than focus on the code I was trying to write :(
@niemyjski i think we need to create a CJS build to go with the ESM build to cover these use cases. There are a lot of platforms that don’t yet support ESM. We do have a dependency on fetch that these older platforms would need to support or we’d have to install a poly fill.
I'm kinda against it as it's something we'd have to support for a very long time for gain in the very short term. There are now thousands of packages out there that only support ESM (like D3) and it's the winner and the future. In October ESM in node goes LTS... It's not even recommended for new libraries to support anything else other than ESM. I'd think if you need to support CJS you'd already have that in your tool chain / bundler. We also say everywhere ESM is required.
What support burden is this adding? The tools we have support outputting to CJS format. There are clearly many things that lag behind and don’t support ESM. I know we have limited resources and can’t support everything, but I’m not sure what this costs us other than having to configure the build to spit out the CJS format build in addition to the ESM one we already have.
Lots of recommendations have this https://www.sensedeep.com/blog/posts/2021/how-to-create-single-source-npm-module.html as a recommendation but there is no way I'm bringing all that mess in. I already went down that path and it was a mess to maintain but outlines some issues with it. I think we could do this: https://github.com/node-fetch/node-fetch/pull/1288/files and just not even commit the cjs artifacts but explicitly say use esm if you can as we will be removing it.
Is there a list of packages that would have to require cjs? At least angular? I'm shocked the node.js isn't using ESM, I'm assuming it will support it soon as it's the default in Node 15+16 which are both current / soon to be LTS.
Also check out the comments in the second link.
Looking at this more, it's not so straight forward as we have custom exports needed to get importing from the dist folder. A part of me want's to just say use the 1.x library as we currently are, maybe we move to cjs for the angular build and you can use that. If you really need it in the short term for node, here is a command line to transpile the dist folder.
"exports": {
".": "./dist/index.js",
"./package.json": "./package.json"
},
It's not a straight forward process as there is different tooling and they might not all treat it the same. Another alternative is maybe we create legacy packages @exceptionless/node-legacy/deprecated? and we just do transpilation. This might be the best approach.
Also, there is only one person asking for this: us right now.
I think this might point to people either not having upgraded to the new JS client or not using JS when using Exceptionless. The reason projects like D3 can exclusively support ESM is because a JS dev can just say npm i @whatever-version-works-for-their-project and get almost all the same functionality. That's not true with this current Exceptionless JS client.
I also think it's worth pointing out that the first two projects I tried since the new client were release had problems of this sort. See this issue: https://github.com/exceptionless/Exceptionless.JavaScript/issues/103
It's unfair to ask developers to jump through configuration and transpiling hoops IMO.
@polluterofminds ideally, but tooling in JS sucks and it's a pain for everyone. Can we do something about it: Yes
@niemyjski i find it hard to believe that it’s that hard to produce CJS builds. We also already have CJS code mixed in with our ESM build from the source map lib. We definitely have work to do on the client still.
For what it's worth, I just spend 30 minutes trying to convert a simple Express.js project to allow for ESM just to be able to use Exceptionless. I would never do that in a real project. I'd switch to Sentry.
We can add a cjs target... We have an express sample using esm (hope you checked there). It's the future everyone will be doing it within the next year when all the libraries move to it.
Also it's not the end of the world, short term sucks, but all starter templates are starting to target esm and thousands of libraries are already targeting esm. If you are using typescript you are already using the correct import syntax and targeting esm is literally changing one property in tsconfig. This argument to me is comparable to complaining about promises because I'm heavily invested in callbacks. I'd love to see the amount of people using cjs and async/await. I think a good chances of people trying to bring this library into a cjs environment won't be awaiting any of our api's because they don't use async / await.
Our goal was to support the modern future of the next quarter-century, not some deprecated module loader. Huge projects will be using bundlers. If your library targets esm, it can consume cjs and esm libraries and will work great with these tools.
@niemyjski you should know by now that everything moves way slower than you think. There are plenty of targets and frameworks and just existing apps that don’t want to convert everything. We need to produce a CJS build and we also need to work towards a full ESM build with regards to the stack trace code we are using. The vast majority of libraries are producing CJS and ESM builds and we should as well. I can help take a look at this, but we’ve done a lot of work on this client and made a ton of great improvements. Let’s not block people from having success with it because of this.
We are making additional changes to greatly simplify our browser dependencies and resolve the issues around umd imports in third party libs.