-
-
Notifications
You must be signed in to change notification settings - Fork 26.8k
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
some pragmatic features #636
Comments
Just suggesting some things from my (a user) point of view.
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.
Search the issues, it's been talked about before. |
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: |
Thanks for raising this and sharing your thoughts!
I’m open to adding this but I’m not sure that blindly allowing everything in We already support running Can you propose a solution to this in a separate issue?
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
Absolutely. We only enable transforms that are:
This is why 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 However if something like 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.
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.
Can you raise a separate issue about this?
It would work by literally adding a
You could also extract it into a 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. |
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 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. |
If you want simple paths like "components/something", how about using local modules ? |
I could get behind |
I prefer a separate "/lib":
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. |
While it's still magical, aliasing // 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 → Is there some sample functionality we could try different suggestions out with to see what directory structures and imports end up looking like? |
@gaearon how is that supposed to help? For example, why would a component be in If we are crazy for asking an easy way to refer to Aliasing |
Another option: just use own package name when importing. To access The Then, to access This way your entry module just happens to be called 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. |
This option would also provide a reasonable solution for #67 because paths would be consistent between browser console and code. |
@ericclemmons I really like the idea of using @gaearon However, it seems the original request is not so much for a place to put local modules as much as a way to For libraries, this would be nice as if you were developing a lib I also like the idea of |
That's exactly what I meant by "local modules". A folder where absolute paths get resolved, in addition to node_modules (hence the name). |
Letting the app use files outside of |
In case of my second proposal, enabling own project to be required by name solves exactly the problem of absolute paths. The only difference is that you have to prefix path with your app's name but that's the prince of safety and obviousness. Anyone who wants less typing can call their package |
Well, those files can only end up in output if somebody imports them on purpose. We don't copy any folders except the build products produced by the bundler, which will only include things that import each other. |
People will import them on purpose. You are at Facebook and working with the best developers in the world. In my case, I need simple and strict rules so people (including myself) don't end up doing something silly. The current rule is "don't touch anything outside of I can't expect everyone to be full-stack and know what API and development secrets are and I can't trust tree-shaking for secrets to be removed. |
Also, this isn't only about leaking secrets. Currently everyone knows what they are supposed to touch and that's always in For example, if you are supposed to implement designs, you touch |
Thanks for all the feedback. I'll look into these further and open up separate PRs. |
Another option is to document usage of something like https://www.npmjs.com/package/linklocal. |
I think an ideal solution for me is if mkdir cool-app
cd cool-app
npm init -y
echo "module.exports = { name: 'chet' }" > defs.js
echo "console.log('hello' + require('cool-app/defs').name)" > index.js
node index.js
> hello chet Thus we're able to reference the package itself just like any other package :) Anyone know where the |
Just in case to clarify, when I said local modules earlier, I meant Here's an example: note how neither webpack, flow, babel or mocha need aliases, NODE_PATH or such to find "component/MyImage" for example. (and if the file was named As for module.resolve, those links might help: Substack had also made a module that implements the same logic: |
Let’s keep this open just so we don’t lose this discussion, and revisit this at some point. |
@cecilemuller do you know where the actual node.js source code is that implements require.resolve? |
My general strategy is to create an PROJECT_ROOT/package.json {
"scripts": {
"postinstall": "link-package ./app app"
},
// ...
} PROJECT_ROOT/app/package.json {
"name": "app",
"standard": {
"parser": "babel-eslint"
}
} PROJECT_ROOT/app/views/Bar/Bar.js import { Foo } from 'app/components/Foo'
// ... If you're in a larger project, you can instead symlink the folders inside app, since you're probably going to end up with lots of common shared components, libs, and utils. PROJECT_ROOT/app/components/package.json {
"name": "components",
"standard": {
"parser": "babel-eslint"
}
} PROJECT_ROOT/app/views/Bar/Bar.js import { Foo } from 'components/Foo'
// ... This is what we use with our reasonably sized react app at Treasure Data. I think it works well. I've read over some of the weirder corner cases, but haven't stumbled into any myself. This doesn't lock you into anything new, if you're already relying heavily on npm. There's so many modules that it's hard to imagine node's resolution algorithm going away any time soon. Aside from that, it tends to make it easy to integrate with other node tools. A typical component folder: I like using Another benefit of using this style of import is that it sometimes makes refactoring stuff a little easier. |
@ccorcos I am not familiar with Node's own sources, but from a quick search, I think this is where: https://github.com/nodejs/node/blob/master/lib/module.js |
@ccorcos if I'm not mistaken, webpack uses its own module resolution that is separate from node's |
Resolve Project Root PR: #651 |
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:
Example: |
Thanks for the summary! I also think Windows Cmd users would need to write it as |
@mandysimon88 but suppose you want to install this package as an npm package and import a specific file -- the paths wont resolve because you need to build a custom build system. on the other hand, if you're resolving to the package name, then everything resolves just fine :) For example, this works just fine: mkdir cool-app
cd cool-app
npm init -y
echo "module.exports = { name: 'chet' }" > defs.js
echo "console.log('hello' + require('cool-app/defs').name)" > index.js
npm link
cd ..
mkdir
cd other-app
npm init -y
npm install --save cool-app
echo "require('cool-app')" > index.js
node index.js
> hello chet And you dont need any special resolver / build system to get it to work because |
I'm not using CRA but I am following many of the decisions/conventions made here closely. I wanted shortened paths for my apps but I didn't want to use Instead I'm using
~module |
That’s fine with me if someone has a better approach. Mine is a “stop-gap."
|
Proposal for absolute imports: #741 |
Going to close this, as it’s best to discuss in separate issues. |
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.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.looks like this project isnt using the babel-polyfill. any reason you opted to use a variety of other polyfills instead?
similarly, is the any reason this project is using a bunch of babel plugins rather than just using the stage-0 preset?
What is the preferred method of sharing CSS variables amongst files? My current solution is to
@import
avariables.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.any interest in adding stylelint as a postcss plugin?
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.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.
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?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 calledchets-build-system
which depends oncreate-react-app-core
and configures it with my custom configs. thecreate-react-app
package can simply have a set of sane defaults but doesnt necessarily have all the feature I want...The text was updated successfully, but these errors were encountered: