(In Scope?) More control over babel-preset based on deployment and target runtime #10646
Unanswered
npetruzzelli
asked this question in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I haven't contributed to create-react-app before, nor have I used Github discussions or Docker, but I will do my best to follow the process correctly.
How I got here
I have an idea, something I've done the work on and am ready to make a pull request for, but the contributing guidelines instruct me to ask the core developers about whether the feature is in scope. When opening a new issue, the template directed me to ask questions here. Please let me know if I've missed a step!
My long term plan is to eventually maintain a fork of
react-scripts
where I can run my unit tests in the browser instead of in node with JSDOM. I have worked on multiple projects that want to use CRA, but JSDOM some components built by team members use APIs or features that JSDOM is not responsible for.karma
and a customjasmine
environment with some modules that consume@jest/fake-timers
,expect
, andjest-mock
to arrive create a reasonable approximation of Jest in the browser.react-scripts
webpack v4 config, I can make a few changes to the returned config to make it work in Webpack 5. Most of this I have working. ReplacingwebpackConfig.node
withwebpackConfig.resolve.fallback
andProvidePlugin
seems to have addressed many of the issues. There are a few other config options that also need migration. Features in Webpack 5 are required to make some test tools intended for Node work correctly in the browser, otherwise this could be accomplished in Webpack v4.My requirements are to use as much of
create-react-app
as possible. When diving into such a large project, I decided to start small, and so I turn my attention first to the babel-preset. The change to the babel config is small, but one that I think will open opportunities in the future if/when CRA wants to look into browser unit testing in the future. It doesn't make sense to me to maintain a fork of the preset, so I am trying my hand here with a feature request and a pull request.Feature Request / Idea
The babel preset currently uses the deployment environment to make some assumptions about the target JavaScript runtime environment. If the deployment is "test", then the runtime must be "node". If "development" or "production" then the runtime must be a web environment (web browser or possibly a web worker).
I want to separate the concerns so that runtime and deployment environments configurations are explicit.
The default behavior based on the deployment environment must be maintained, but a preset option would allow it to be explicitly set. This is to support browser test environments along side node test environments.
Many configuration settings are truly dependent on the deployment environment, not the runtime environment, and these settings will remain unchanged.
You can compare Facebook's master branch with my feature branch here:
master...npetruzzelli-forks:babel-preset-runtime-option
I tried to take care so as not to confuse the new option with the option related to configuring
@babel/plugin-transform-runtime
.I did not open a pull request as the instructions seemed to recommend getting feedback first instead of opening an unsolicited PR.
Testing Method
I've attempted running the e2e and test scripts. It looks like they pass, but then the
e2e:docker
script fails with something that seems unrelated to the test results itself. It could that I've set up Docker incorrectly.As an additional check, I've created a new app with CRA, applied these changes to the copy of the preset in the local
node_modules
directory, and ran thestart
,build
, andtest
scripts, which all seemed to function normally.Beta Was this translation helpful? Give feedback.
All reactions