Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
This ES modules build will make these modules smaller in the final
I considered adding a module field to the package.json to point to this
For now, consumers will need to use this either by importing from
When working on this I originally kept the plugins array at the top
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.
Here's the error I'm getting:
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?