-
Notifications
You must be signed in to change notification settings - Fork 201
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
Load Rollup configs with import(...)
to fix warning
#3840
Conversation
Convert the Rollup config files to have a `.mjs` extension so that Node can natively load them as ES modules and then load them using `import(...)` rather than the `loadConfigFile` helper. This avoids a deprecation warning when importing `rollup/dist/loadConfigFile`: ``` (node:21339) [DEP0148] DeprecationWarning: Use of deprecated folder mapping "./dist/" in the "exports" field module ... ``` This also makes the way the config file is loaded more transparent, since its just a regular dynamic import. The downside of this change is that we don't get a `warnings` object back to print warnings that occur during bundling. Instead have to pass an `onwarn` handler to `rollup.{rollup, watch}`.
Convert Rollup configs to native ES modules and load them with `import(...)`. This avoids a deprecation warning from Node triggered by the `loadConfigFile` import. See also hypothesis/client#3840
Change bundling in development and when running tests to use Browserify rather than Rollup. This adapts the changes that were recently made in the lms [1] and client [2] projects. [1] hypothesis/lms#3221 [2] hypothesis/client#3840 This follows the pattern and reuses code from the re
Change bundling in development and when running tests to use Browserify rather than Rollup. This adapts the changes that were recently made in the lms [1] and client [2] projects. [1] hypothesis/lms#3221 [2] hypothesis/client#3840
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.
This makes good sense based on the PR description 👍🏻
import alias from '@rollup/plugin-alias'; | ||
import babel from '@rollup/plugin-babel'; | ||
import { babel } from '@rollup/plugin-babel'; |
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.
o_O
if (!Array.isArray(configs)) { | ||
configs = [configs]; | ||
} |
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.
Is there a valid normal condition under which this would occur? Just curious.
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.
rollup-tests.config.js
exports a single object rather than an array. I suppose we could make that export an array as well, but that would be unconventional for a single-output Rollup config.
Change bundling in development and when running tests to use Rollup rather than Browserify. This adapts the changes that were recently made in the lms [1] and client [2] projects. [1] hypothesis/lms#3221 [2] hypothesis/client#3840
Convert Rollup configs to native ES modules and load them with `import(...)`. This avoids a deprecation warning from Node triggered by the `loadConfigFile` import. See also hypothesis/client#3840
Convert the Rollup config files to have a
.mjs
extension so that Nodecan natively load them as ES modules and then load them using
import(...)
rather than theloadConfigFile
helper.This avoids a deprecation warning when importing
rollup/dist/loadConfigFile
:This also makes the way the config file is loaded more transparent, since its
just a regular dynamic import.
The downside of this change is that we don't get a
warnings
objectback to print warnings that occur during bundling.
Instead have to pass an
onwarn
handler torollup.{rollup, watch}
. On the other hand, emitting warnings this way avoids mistakes where the caller forgets to callwarnings.flush()
.One other side effect of this is that
require
can no longer be used in the.mjs
files to load JSON modules. Insteadpackage.json
has to be read usingreadFileSync
and parsed usingJSON.parse
(related reading). If we're going to start using ES modules for regular Node scripts in future we might as well get used to differences in how certain things have to be written though.