Add /esm build #791
Merged
Add /esm build #791
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
These three files are used as entry points into the project, and we expect people to be importing them directly so they are at the top level for convenience. Because of this, they have not been getting run through Babel like the rest of the code here, so they were using older syntax. In this commit, I am moving these files into the src directory so they will be built into lib like the rest of the code here. In their place at the top level, I am creating some very light shims that simply bring in the built version of the module and re-export it if necessary. This gives us a couple of advantages. First, it makes more of our code consistent. Second, it makes it possible to produce two different kinds of builds, one for CommonJS consumers and another for ES modules consumers.
This ES modules build will make these modules smaller in the final bundles, since the way Babel compiles import to require is pretty verbose. Additionally, it will enable webpack to make some optimizations on the final bundle, including tree-shaking and scope hoisting (if enabled). These will improve bundle sizes and runtime performance. I considered adding a module field to the package.json to point to this version for folks who are able to use it, but I decided to wait on that for now since that is still pretty experimental. For now, consumers will need to use this either by importing from react-dates/esm directly or by using something like a webpack alias to use this version of the build. When working on this I originally kept the plugins array at the top level instead of repeating it for each env, but I ran into an issue that seemed related to ordering that caused babel-register in the compile CSS script to not apply the correct transformations. I was able to work around this by repeating the plugins for each env.
lencioni
force-pushed
the
jdl-esm-build
branch
from
5424418 to
2124613
Compare
ljharb
approved these changes
Oct 23, 2017
| toLocalizedDateString: toLocalizedDateString, | ||
| toMomentObject: toMomentObject, | ||
| }; | ||
| // eslint-disable-next-line import/no-unresolved |
There was a problem hiding this comment.
i don't think this is needed; it's fine if the linter requires the build process be ran first.
There was a problem hiding this comment.
I mostly wanted to get rid of the error messages for myself when I was working in these files.
There was a problem hiding this comment.
npm run build would have done that :-p
There was a problem hiding this comment.
And then npm run clean would have broken it again :-P
There was a problem hiding this comment.
It’s not a blocker; but in general I think the warnings there are good; without them, you might unintentionally have a bad path. I don’t think it’s a good idea to optimize for the development case when it subtracts from production safety ¯\_(ツ)_/¯
| @@ -1,4 +1,2 @@ | |||
| // eslint-disable-next-line import/no-unresolved | |||
| } | ||
| "presets": ["airbnb"], | ||
| "plugins": [ | ||
| "inline-react-svg", |
There was a problem hiding this comment.
super gnarly that we have to repeat these two plugins in every env due to ordering issues
|
@lencioni @ljharb I think this change affected the gh-pages script which builds storybook. Specifically, I think it is using a babel environment that has no associated setting in the Here's the error I'm getting: |
|
Yep seems likely. Do you know what env it uses?
|
|
I think it builds in production mode, but I'm unsure. EDIT: yup, it looks like it does Do we have to add another setting for that? |
lencioni
added a commit
that referenced
this pull request
Oct 27, 2017
In #791 I added an ESM build, but ended up breaking the production build for gh-pages. Storybook builds with NODE_ENV=production, so this should fix that problem.
devs-cloud
pushed a commit
to devs-cloud/react-date
that referenced
this pull request
Dec 27, 2019
In react-dates/react-dates#791 I added an ESM build, but ended up breaking the production build for gh-pages. Storybook builds with NODE_ENV=production, so this should fix that problem.
MarcoAntonioAG
pushed a commit
to MarcoAntonioAG/React-dates
that referenced
this pull request
Mar 31, 2022
In react-dates/react-dates#791 I added an ESM build, but ended up breaking the production build for gh-pages. Storybook builds with NODE_ENV=production, so this should fix that problem.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This ES modules build will make these modules smaller in the final
bundles, since the way Babel compiles import to require is pretty
verbose. Additionally, it will enable webpack to make some optimizations
on the final bundle, including tree-shaking and scope hoisting (if
enabled). These will improve bundle sizes and runtime performance.
I considered adding a module field to the package.json to point to this
version for folks who are able to use it, but I decided to wait on that
for now since that is still pretty experimental.
For now, consumers will need to use this either by importing from
react-dates/esm directly or by using something like a webpack alias to
use this version of the build.
When working on this I originally kept the plugins array at the top
level instead of repeating it for each env, but I ran into an issue that
seemed related to ordering that caused babel-register in the compile CSS
script to not apply the correct transformations. I was able to work
around this by repeating the plugins for each env.
@airbnb/webinfra