some pragmatic features

[ccorcos]

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...

[tbillington]

Just suggesting some things from my (a user) point of view.

Absolute imports

#276 #253

Custom environments

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

Library

Not sure this is the aim of this project, 'create-react-app' rather than 'create-react-lib'. It might be best to look for other boilerplates ? Otherwise you could eject and modify the webpack build to a library.

config

Search the issues, it's been talked about before.

[insin]

how to build component library package?

#423

zero-configuration (configurable) build tool

This isn't currently a goal of create-react-app.

Check out some of the alternatives if this is what you're after - the following allow configuration to different degrees:

• nwb
• sagui
• roc
• mozilla-neo
• tarec

[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: #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.

[AlicanC]

absolute imports

I have made the terrible decision of giving all general-purpose directories their own alias in a few projects. I ended up with multiple aliases like components => src/components, helpers => src/helpers, etc. and they became hard to maintain since I had to duplicate all of them for Flow too. Currently I only use one alias, app => src, and it helps a lot.

Of course the name "app" is taken and can cause conflicts. A better name (something that can't be an npm package name?) can be chosen for this.

[cecilemuller]

If you want simple paths like "components/something", how about using local modules ?
The name "node_modules" is not just for thirdparty code from npm (npm just uses it because it's how Node resolves paths). Then you have clean paths without needing folder aliases in every tool of the stack, non-cross-platform hacks, or extra dependencies :)

[gaearon]

I could get behind src/modules.

[ericclemmons]

I prefer a separate "/lib":

https://medium.com/@ericclemmons/dogfooding-your-open-source-projects-9e6dc1e7d1c8

It helps within our codebases to have a "staging" area outside of "src". In the past, you'd often have a "utils" folder with generic utilities.

The intent was to make clear that these should become open-sourced libraries.

[insin]

While it's still magical, aliasing src to src feels like the least magical solution to avoiding ../ path traversal to me, as the resulting top-down import paths match what you're seeing in your editor.

// From somewhere deep under src/routes/
import LoadingButton from 'src/components/LoadingButton'
import Spinner from 'src/components/Spinner'
import {createActionDispatchers} from 'src/utils'

I usually group these together as a separate import block to try to make that even clearer (Node.js built-in imports → node_modules/ imports → top-down imports → local imports).

Is there some sample functionality we could try different suggestions out with to see what directory structures and imports end up looking like?

[AlicanC]

@gaearon how is that supposed to help? For example, why would a component be in src/components instead of src/modules/components or vice versa?

If we are crazy for asking an easy way to refer to src, then it must be considered bat-shizzle crazy to use @providesModule. How is it okay to do import X from 'X'; (which gives you no freaking idea where "X" is and what its purpose is) and not okay to do import X from 'app/components/X'; (which shows you where it is and also that it's a React component)?

Aliasing src is just a better @providesModule.

[gaearon]

Another option: just use own package name when importing.
Resolves relative to project folder.

To access my-app/src/stuff/index.js, import from my-app/src/stuff.

The src part is redundant so instead we can encourage people to put "modules" into the root folder. We would also enable Babel on the whole project directory (except node_modules).

Then, to access my-app/stuff/index.js you would import from my-app/stuff.

This way your entry module just happens to be called src but you can add other modules, and absolute paths are obvious (they include the app name) and work the same way.

And you can't accidentally import the wrong thing because your app cannot be dependency of itself (npm won't allow it). So it can't ever be a dependency.

[gaearon]

This option would also provide a reasonable solution for #67 because paths would be consistent between browser console and code.

[mlrawlings]

@ericclemmons I really like the idea of using lib/ to stage modules. That makes a lot of sense. You could also use app-module-path for the node side of things.

@gaearon However, it seems the original request is not so much for a place to put local modules as much as a way to require files using a path based at the root of the project. I've always thought it would be nice to be able to require the current project by name (search up the directory tree for a package.json and if your require matches the name entry it uses that as the starting point).

For libraries, this would be nice as if you were developing a lib foo, you could require('foo') in any examples and tests within your project and they would work, but also be portable.

I also like the idea of ~ being aliased to the current project. So you could require('~/src/foo.js') and although this would conflict with the unix-style home directory alias, I'm willing to bet you're doing something you shouldn't be doing if you're trying to require something from your home directory. This may be taking things too far, but I thought I'd throw it out there.

[gaearon]

However, it seems the original request is not so much for a place to put local modules as much as a way to require files using a path based at the root of the project

That's exactly what I meant by "local modules". A folder where absolute paths get resolved, in addition to node_modules (hence the name).