Fix importing from ES module - #25
Conversation
|
Dirk Bäumer (@dbaeumer) any comments? :) |
|
That's more Johannes Rieken (@jrieken) |
|
Any interest in getting this? It will likely be a breaking change for consumers with |
|
Rafał Chłodnicki (@rchl) VS Code extension cannot really use ESM (yet) so I wonder where/how you would use this? |
|
Some language servers / services use it. Also VSCode extensions are often bundled using esbuild. In this case CJS will result in boilerplate code in the bundle to provide CJS interoperability. In most cases this could be replaced with WHATWG URL though. I think the question shouldn’t be where / how this would be used though. This package already contains ESM. If an npm package is published containing ESM, IMO it should contain real ESM, not faux. That’s what this PR is about. |
|
I guess I'll reiterate most of the points that Remco Haszing (@remcohaszing) made already but I'm using it in https://github.com/typescript-language-server/typescript-language-server/ and as Remco Haszing (@remcohaszing) pointed out, this package is already set up with ES bundle (the |
|
And to clarify more: this change doesn't make it a "ES modules only" package which would be the case if it had a |
|
Any progress here? The bug is that |
Previously only a umd main entrypoint. There was also the non-standard `module` field in `package.json`, which causes issues with various tools. Now the standard `package.json` field `exports` is used to support both native ESM and CJS. Additionally, the webpack build has been replaced with `tsc`. Instead of bundling `path-browserify`, an import condition is used to select either `path` or `path-browserify`. This means that browser users use `path-browserify`, regardless of whether they use ESM or CJS, whereas others use `path`. Also this means users can deduplicate `path-browserify` if they use it elsewhere in their code base. Closes microsoft#25 Closes microsoft#33 Closes microsoft#37
Previously only a umd main entrypoint. There was also the non-standard `module` field in `package.json`, which causes issues with various tools. Now the standard `package.json` field `exports` is used to support both native ESM and CJS. Additionally, the webpack build has been replaced with `tsc`. Instead of bundling `path-browserify`, an import condition is used to select either `path` or `path-browserify`. This means that browser users use `path-browserify`, regardless of whether they use ESM or CJS, whereas others use `path`. Also this means users can deduplicate `path-browserify` if they use it elsewhere in their code base. Closes microsoft#25 Closes microsoft#33 Closes microsoft#37
|
Fixed by #39 |
6 participants
This should fix the case when consumer of this package uses
type: 'module'inpackage.json.The issue with that was that in that case Node.js would resolve the import to the UMD bundle and then importing with
import { URI } from 'vscode-uri'would not work. Only a hacky way likeimport vscodeUri from 'vscode-uri'; vscodeUri.URI(...);would work.I can make an example repo to demonstrate the issue if you want.
(Note that the
modulefield inpackage.jsonis ignored by Node.js so that's why I've addedexports. Themodulefield is only supported by bundlers like Webpack.)BTW. Please sort out this repo first --
mainis lagging behind as there is a 3.0.3 tag but changes from it are not merged to it.(And this repo could have issues enabled as there are some type of issues like this one that don't belong in vscode repo itself.)