It seems a strict CSP for style-src will be unhappy when webpack's style-loader tries to append inline CSS in a create-react-app (CRA):
I was wondering if I need to use a webpack dev server to take advantage of using a nonce token, or if CRA had a way of circumventing this style issue during development. The REACT_APP_INLINE_RUNTIME_CHUNK=false value doesn't seem to help in this case (in fact, I'm not seeing a difference in the resources that come over the wire between setting it to true vs. false). But I am running npm start instead of npm build, I think the latter properly builds with environmental variables, not sure about the CRA dev server.
From what I can tell, CRA doesn't really want you overriding things. But if you must, you can use something like react-app-rewired, or eject (which is strongly advised against because it will derail package updates CRA uses to keep everything nice and neat and working).
There's also modifying the build files themselves in node_modules/react-scripts/config/webpack.config.prod.js, although what I'm currently doing is commenting-out the meta tag during development and uncommenting on submit, which is about the same amount of work I think if I have to rebuild/reinstall on updating the module anyway. Although I don't typically update it that often.
Source: https://stackoverflow.com/a/64361307/1580355
Related
I'm building an application with vue-cli and I see that webpack config is not explicitly defined in my repo. It's hidden from us (although it can be changed). Default run dev script by vue-cli also use vue-cli-service instead of webpack.
I'm a questionning myself about the consequence of this.
Are we losing control over the webpack config?
Does new version could modify the base hidden config without us knowing it ?
Are vue-cli taking too much space and break some decoupling principle (since it will be more difficult to change from webpack to another bundler for example) ?
Thanks in advance.
Regards
(English not my primary language, sorry)
No modern framework's CLI (including Vue) is going to operate not according to best practices.
You can read on how to work with Webpack in Vue here: Link.
New versions with breaking changes are documented like so: Link.
An application built on any framework will depend on that framework, regardless of CLI use. Configurations built from the CLI can always be changed manually.
Recently, node package manager is very popular and doing a lot of job for us, however it is really difficult to understand what is going on under the hood. I really like simple tags to insert Vue, Babel etc. Haven't worked on big projects, I really wonder is there any disadvantages using script tags over npm-cli.
When you npm install a library, plugin, extension, etc it can be declared as a dependency with a --save flag. In doing so it is marked as a dependency in your package.json file, which is key to version control for your dependencies. If you just use the CDN you are pulling in a path to a library that may be deprecated at some point in the future.
During development it is ok to use CDNs, but in production it is not good practice for dependencies (though I do it for certain exceptions, such as a google font).
I am being thrown a half backed, undocumented, non-handover project of VueJs with few other components as frontend and express as a backend. (Old developer who was maintaining things on git is abscond)
Backend/Express part I've figured it out most of the things but I got stuck on frontend part which is served using express_static
For VueJs I don't know what other things are depending
Is it using yarn or npm for build/deploy ?
Using mostly command line
What should be my starting point to look into project
Build/deploy yarn <> npm is interchangeable.
Is it possible to convert Individual .vue file to .js file and deploy it?
What other tips and tricks you suggest for making quicker changes live on productions without major disaster (on front-end side).
What is the fastest way to hack things in this situation :)
Is there any docs what happen internally? - Curious to know!
Thanks
I have projects to maintain that use node-sass npm module.
Since node 10.x, there is a tool (called npm audit) that is run every time we do a npm install. This seems to be a good tool for preventing vulnerability issues.
My problem is that the node-sass module has vulnerabilities. I saw that the maintainers of the project do not want to fix the issues with bad reasons.
https://github.com/sass/node-sass/issues/2262
People maintaining popular module like node-sass should correct as soon as possible the vulnerability issues, but unfortunately they don't.
I am not an expert in Security, so I prefer to rely on what indicates npm and not use anymore dependencies that print messages that let you think your software is crap.
But I like so much SASS for coding CSS that I would like to give it a chance to keep it.
Any idea for removing these vulnerability messages while keeping the project safe and not reducing developer experience ?
This security issue is mainly irrelevant to node-sass since it never sees any exposure to your live code.
node-sass runs on hosts normally used for development and usually are not visible in a public network.
You normally will use node-sass to pre-compile SCSS into CSS and vulnerabilities will not impact the resulting CSS code.
These warnings are relevant if you run the node.js server as a backend which is normally not the case. (or never the case)
One option is to use dart-sass. It has no vulnerability issues.
https://sass-lang.com/dart-sass
https://github.com/webpack-contrib/sass-loader
I am curious to know why when I create a new Aurelia project, each project installs +600 node_modules. Understandably, the modules collectively don't take up a lot of space, but are all of these modules necessary? I was under the impression that Aurelia's aim was to help developers move away from depending on 3rd party libraries so it seems odd that each project comes with a massive dump of 3rd party libraries.
My guess is that you are starting your project from CLI - which comes preset with HTTP server, ES6/2015, SASS, live-reloading and more.
I created clean Aurelia project and looked at the package.json - there were 5 dependencies and 34 dev dependencies. Using all of above mentioned tools is somewhat standard in today's JS web development, and generating project from CLI reduces time needed for upfront setup. All of these features come with their own dependencies, and that's why node_modules/ folder grows rapidly.
The bottom line is - you could start new Aureila project with much fewer dependencies. On their home page you can find starter project with just three. But that also means that you won't have access to most of the tools used today.
Also, and correct me if I'm wrong, I haven't got the impression Aurelia ever aimed to move devs from third party libs and modules, just to be modern, fast, and unobtrusive.
All modern web frameworks have a host of tooling. The reasons in no particular order -
1. Transpiling ESNext or TypeScript - if you want to write in Future JavaScript but have it work in all browsers, you need this step. Both Babel and TypeScript tooling comes with extra stuff too. If you want to see coverage (everyone does) there's another tool.
2. Testing - Unit test and End to End testing require testing frameworks, test runners, and if you want to write like above (esnext or TypeScript) you also need transpiling.
3. Module Loading / Bundling - Require.js, JSPM/System.js, WebPack, etc... are used to allow your code to actually run in the browser. Without a module loader you could not break your code out in to separate files. Without a bundler you would be loading a lot of extra files in production.
4. Serving your application - If you want to run your app locally you need a way to serve it up and watch for changes.
5. Debugging - You want to debug? Now you need a way to debug the file that gets served to the browser back to the original source.
6. Linting - Lint your code base for style consistencies.
Each of these packages usually have their own dependencies, and they get pulled down as well.
This convention of small packages that have a single focus is arguably better than massive packages that do everything for you. This allows you to remove a package and replace it with the one that does the same thing but in a way you want it.