-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Added "exports"-field to package.json so import/require loads the appropriate file without any additional user-input #1725
Conversation
Signed-off-by: kilian <kilian@catsoft.com>
Signed-off-by: kilian <kilian@catsoft.com>
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/markedjs/markedjs/j688ptxsg |
Signed-off-by: kilian <kilian@catsoft.com>
According to Node:
So we will need to do a major version bump for this. |
"@types/node": "^14.0.9", | ||
"babel-eslint": "^10.1.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why are these extra dependencies on here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nodejs typings and a linter that doesn't croak on encountering stage3 ES-features. this was a rather hasty PR so i forgot to remove my devDeps.
There's little use for the linter if you don't use features released in after 2018.
node typings are always usefull. i don't think you use any builtins in the main code, but the tests do. i honestly recommend adding them to any project.
I also don't believe we should implement this until es modules are not experimental as the interface could still change. It seems this is only supported in node v14+ so we should probably wait until v14 becomes LTS. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to Node:
Warning: Introducing the
"exports"
field prevents consumers of a package from using any entry points that are not defined, including thepackage.json
(e.g.require('your-package/package.json')
. This will likely be a breaking change.So we will need to do a major version bump for this.
Is importing a package.json a "common" occurance? Just screams bad practice to me. But if that's something that people do, then it's certainly a point to consider.
LTS for node v14 is shockingly close already i just realised (scheduled for late october as always). I think this can wait till then
"@types/node": "^14.0.9", | ||
"babel-eslint": "^10.1.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nodejs typings and a linter that doesn't croak on encountering stage3 ES-features. this was a rather hasty PR so i forgot to remove my devDeps.
There's little use for the linter if you don't use features released in after 2018.
node typings are always usefull. i don't think you use any builtins in the main code, but the tests do. i honestly recommend adding them to any project.
Not |
This would be the files in |
This isn't true. ESM was introduced in Node 13.x and back ported to 12.x LTS. With 10.x being EOL'd there is no longer an officially supported version of Node that doesn't work with modules. For the issue of direct path imports being unavailable after pkg.exports is introduced. Instead of defining an export for every file you can provide a facade instead that re-exports all of the modules. Like this (https://github.com/vanillaes/absurdum/blob/main/src/arrays/index.js) but using default exports because none of the existing components are written in ESM. If you don't want to support 2 copies (ie CJS and ESM), you can always use RollupJS or ESBuild to convert from ESM to CJS. ESM -> CJS conversion is a LOT cleaner than CJS -> ESM. |
If this PR was rebased I would be fine with including the exports field now 👍 |
".": { | ||
"import": "./lib/marked.esm.mjs", | ||
"require": "./src/marked.js" | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you should also export package.json
as some bundlers will want to read it
} | |
}, | |
"./package.json": "./package.json" |
@@ -0,0 +1,2206 @@ | |||
/** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this file is going to be added then the old lib/marked.esm.js
should be removed, but it shouldn't be necessary to name it with an .mjs
extension
closing this in favor of #2227 |
Marked version: @latest
Markdown flavor: n/a
Description
.mjs
lib/marked.esm.mjs
I did a superficial test to ensure the paths are correct.
VSCode debugger showed that
import marked from 'marked'
will only loadlib/marked.esm.mjs
citing my comment
Contributor
Committer
In most cases, this should be a different person than the contributor.