some pragmatic features

Hey there, I’m considering dropping my existing build system in favor of create-react-app, but there are a few features that I would need. At some point, I’ll likely need to fork, but until then, I’m curious if any of these features appeal to you enough to open up a PR.

• absolute imports

In a large codebase, relative paths can get really annoying and make it hard to determine where files are being used. I’d like to suggest aliasing the project name to the root of the project. That way you can write something like import Env from 'create-react-app/config/env'. And if you want to find out where this file is used, its a simple find-all query for the file path.

• babel-polyfill

looks like this project isnt using the babel-polyfill. any reason you opted to use a variety of other polyfills instead?

• stage-0 preset

similarly, is the any reason this project is using a bunch of babel plugins rather than just using the stage-0 preset?

• postcss variables / imports

What is the preferred method of sharing CSS variables amongst files? My current solution is to @import a variables.css file that doesnt generate any css so long as autoprefixer is prefixing for a browser that doesnt support css variables. I’m not sure this is the best solution since eventually this will result in duplicate css once browsers support css variables. But I dont want to rely on magic globals either.

• stylelint

any interest in adding stylelint as a postcss plugin?

• configurable environments / feature flags

I’d like to be able to run the application from the cli specifying the NODE_ENV and/or feature flags that use the define plugin. Something like NODE_ENV="replay" npm start which would let me start up the app in development mode with my replay devtool so I can run through various pre-recorded redux scenes.

• deploy elsewhere

We’re deploying our stuff to S3. Given this is a “zero-config” build tool, I’m not sure how adding an s3 deploy script would work.

• how to build component library package?

Suppose I have a bunch of shared React components. How would I build this package so that I can publish it on NPM and require it from another project? The fact that babel isnt parsing node_modules means that we need to build a distribution file. But we also shouldnt be minifying or hashing the filenames, and we also dont need an index.html file. Any ideas how we could outfit this tool to work for React component libraries?

• zero-configuration (configurable) build tool

this all leads me to thinking that maybe the right way to go is to have a configurable build tool with some zero-configuration defaults. how to I set the eslint config, flowtype config, stylelint config, babel config? I dont want to rely on a .babelrc or something that I have to copy into all of my projects. Ideally, I could create a package called chets-build-system which depends on create-react-app-core and configures it with my custom configs. the create-react-app package can simply have a set of sane defaults but doesnt necessarily have all the feature I want…

[gaearon]

Thanks for raising this and sharing your thoughts!

absolute imports

I’m open to adding this but I’m not sure that blindly allowing everything in src to be referenced absolutely is a great way of doing it. Particularly I saw confusion from beginners who used boilerplates with absolute imports, named their folders react or redux, and started getting conflicts with node_modules.

We already support running npm start, npm run build, or npm test, with NODE_PATH environment variable, which sort of lets you do that explicitly. Like NODE_PATH=./src npm start. But I can see that this might feel a bit frustrating.

Can you propose a solution to this in a separate issue?

looks like this project isnt using the babel-polyfill. any reason you opted to use a variety of other polyfills instead?

It’s quite heavy. People already blame React for “being large”. We don’t want to prescribe a large polyfill when many users opt to not use runtime ES2015 features, or use them at their own risk. We encourage people to add granular polyfills for features they actually use instead.

We opted to add a Promise and fetch polyfills because we consider them to be fundamental to doing async in React apps these days. Also people often choose bad Promise polyfills that don’t log unhandled rejections, and then blame React for “swallowing” their errors, which is not true. So we prefer to have control over that. On the contrary, features like Array.from() are not fundamental, so we’d rather give control over them to the user.

similarly, is the any reason this project is using a bunch of babel plugins rather than just using the stage-0 preset?

Absolutely. We only enable transforms that are:

• Either stable;
• Or actively used at Facebook.

This is why class-properties and async/await are enabled but decorators are not.

Our reasoning for this is also simple. We think some of these experimental features provide enough value that we’re willing to enable them even at the cost of the churn later. However we never want to expose our users to this churn.

If class-properties doesn’t work out, we’ll write a codemod at Facebook and share it with the community, so that people can migrate away from it. We know it’ll work well because we’ll also use it internally for thousands of components at Facebook.

However if something like decorators doesn’t work out, or changes syntax, we know we won’t be able to write a good codemod for it because we just don’t use this proposal for our components. So we’d essentially leave users relying on it in the dark, which is in direct opposition to Create React App philosophy.

To sum up: we only enable plugins that work great together, and that we commit to supporting through codemods in case of changes or deprecations.

What is the preferred method of sharing CSS variables amongst files? My current solution is to @import a variables.css file that doesnt generate any css so long as autoprefixer is prefixing for a browser that doesnt support css variables. I’m not sure this is the best solution since eventually this will result in duplicate css once browsers support css variables. But I dont want to rely on magic globals either.

There is an issue about this: https://github.com/facebookincubator/create-react-app/issues/130. Unfortunately nobody came up with a PR yet, would you like to give it a try? As elsewhere, we are open to enabling features that are low-risk, high-value, relatively stable, and are future standard compatible.

any interest in adding stylelint as a postcss plugin?

Can you raise a separate issue about this?

I’d like to be able to run the application from the cli specifying the NODE_ENV and/or feature flags that use the define plugin. Something like NODE_ENV=“replay” npm start which would let me start up the app in development mode with my replay devtool so I can run through various pre-recorded redux scenes.

https://github.com/facebookincubator/create-react-app/blob/master/template/README.md#adding-custom-environment-variables

We’re deploying our stuff to S3. Given this is a “zero-config” build tool, I’m not sure how adding an s3 deploy script would work.

It would work by literally adding a deploy entry to scripts in your package.json that does what you need. For example it could look like this:

  "deploy": "npm run build && node ./my-scripts/deploy.js"

You could also extract it into a package.

how to build component library package?

Not currently supported, but experiments are welcome. We can’t solve all use cases right now, let’s figure out apps first 😉 .

---

I’ll close this issue because it’s a bit too meta, and in my experience such issues don’t really move projects forward. I hope my replies show future work directions for each of these items, and you are welcome to submit PRs or file new issues for the actionable items that you care about.

[amandapouget]

Recognize the discussion above gets into this with more complexity, but for anyone stumbling across this and looking for tl;dr:

Absolute imports (of things in the src folder) can be accomplished with this simple modification to your package.json:

    "start": "NODE_PATH=src/ react-scripts start",
    "build": "NODE_PATH=src/ react-scripts build",
    "test": "NODE_PATH=src/ react-scripts test --env=jsdom",

Example: import { Banana } from 'fruits/yellow/big/Banana' where fruits is a subdirectory of src.