Skip to content
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

Stop webpack from resolving symlinks to real folders #3695

Closed
wants to merge 1 commit into from
Closed

Stop webpack from resolving symlinks to real folders #3695

wants to merge 1 commit into from

Conversation

iamandrewluca
Copy link
Contributor

@iamandrewluca iamandrewluca commented Jan 5, 2018

Webpack will not resolve symlinks to real folders
This allows to symlink into src folder
https://github.com/facebookincubator/create-react-app/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+symlinks

fixes: #3547 and others...
closes: #3689

Webpack will not resolve symlinks to real folders
This allows to symlink into 'src' folder
https://github.com/facebookincubator/create-react-app/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+symlinks

fixes: #3547 and others...
@facebook-github-bot
Copy link

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need the corporate CLA signed.

If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks!

@facebook-github-bot
Copy link

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

@gaearon
Copy link
Contributor

gaearon commented Jan 9, 2018

If this was a panacea wouldn't it be enabled by default in webpack itself? What are the tradeoffs and downsides of this?

@iamandrewluca
Copy link
Contributor Author

It seems that this option was added one year ago. Maybe it has default to true, to not break back compatibility. For Windows users can't have this I think. I can't find any downsides for now. Maybe folks from community know better what would break this.

webpack/enhanced-resolve@c2f517e

@iamandrewluca
Copy link
Contributor Author

Having this, you could link uncompiled sources from outside of src into it, and have them compiled by Babel.

@iamandrewluca
Copy link
Contributor Author

For now I dont't see symlink as a solution. Starting to get more problems.

@gaearon
Copy link
Contributor

gaearon commented Jan 11, 2018

Can you elaborate? Would be helpful for future attempts.

@iamandrewluca
Copy link
Contributor Author

iamandrewluca commented Jan 11, 2018

I have to create 3 react apps (using create-react-app) with common frontend components.
I created common using storybook. For styling I extended bootstrap with sources (*.scss) also in common. I also have some static images and fonts in common. Development is working fine.

Some dependencies are as dev and peer.
I have them installed in common and each app#
react/react-dom/bootstrap/reactstrap

As my components sources are not compiled, installing common as npm dependency for app# will not work, because webpack and babel-loader excludes node_modules from compiling process and I get an error that I need an loader for that file type.
If I had my common parallel to my app# I couldn't include components using relative path because create-react-app does not allow importing outside src except node_modules (cap obvious) 😄 . Solution was to symlink node_modules/common into src/common

I ejected create-react-app, and disabled Webpack resolve.symlink and created symlink mentioned above. Now *.js files are compiled fine without errors.
Even with npm link everything is working fine. somepath/common -> node_modules/common -> src/common

Here comes styles/images/fonts 😃 .
In common I extend bootstrap this way. I have:

// src/scss/_buttons.scss
@import "~bootstrap/scss/buttons":
// ... my styles

// src/scss/_variables.scss
@import "~bootstrap/scss/variables":
// ... my vars

// src/font/font-faces.css
// src/font/font.ttf

// src/scss/bootstrap.scss
@import "../font/font-faces.css";
@import "variables";
@import "buttons";
// ... other imports

In app# I am compiling sass from common using create-react-app tutorial. Parallel compiling sass and js.
In app# I have src/index.scss that gets compiled to src/index.css and included in index.js

// src/index.scss
@import "~common/src/scss/bootstrap";

This import does not work. I have to make it relative to symlinked one src/common
And also get errors already from common imports they don't find ~bootstrap
Had to change them relative also in common to ../../node_modules/bootstrap.
But if I want to make this work also in dev mode, I have to keep same folder structure relative to node_modules in common and all app# (what a mess) 😆
Now everything works, I get compiled css, but now css-loader from create-react-app sees url to images and fonts, realtive to app#, and can't find them, I have to copy them manualy into each app#

In conclusion. As I already ejected create-react-app for symlinks.

  • I will keep it this way, and add sass-loader and make it work, to find fonts and images.
  • I will remove src/common symlink, and adapt babel-loader to include node_modules/common into build.
  • Now I can also remove service worker fallback paths 😐

Also my coworkers that are mostly back end (Java) devs said that I am making kind of "bicycle" with all this symlinks. And would be better to compile common and publish it into our pirvate maven nexus, and install it from there.
But I am struggling about dev mode. Because now at beginning will be a lot of changes, and I don't want to compile and publish common ech time.
Was the idea to have all in one project and to have app#.js foreach app and change to index.js for at build time, but we have some limitations from maven side, As all 3 app# have to be build into diffrent jars

I have to integrate all this into maven build process and CI process.
Or to rethink all build process again.
Will be a fun weekend 😄

@gaearon
Copy link
Contributor

gaearon commented Jan 21, 2018

All of this sounds like something that could be solved by #3741, no?

@lock lock bot locked and limited conversation to collaborators Jan 20, 2019
@iamandrewluca iamandrewluca deleted the not-resolve-symlinks branch July 26, 2019 19:27
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Symlink behaviour Importing components from another package
3 participants