I found a Webpack module https://github.com/webpack-contrib/css-loader#css-modules
which is able to rename class names and makes class names unreadable.
I found a SO answer here https://stackoverflow.com/a/14751344/5369031 but I am very curious how we can achieve the same thing in Angular CLI during ng build --prod ?
Unreadable means:
What https://github.com/webpack-contrib/css-loader#css-modules does is enabling CSS Modules.
I was able to implement CSS Modules in an Angular 8 application (it's possible to do it in Angular 7 or higher too) customizing the build thanks to #angular-builders/custom-webpack and then using postcss-modules and posthtml-css-modules.
postcss-modules hash all the styles, then posthtml-css-modules replaces the class names on the html files by the hashed class names.
I documented my solution here:
Live Demo: https://angular-css-modules.herokuapp.com/
Github Repo: https://github.com/gquinteros93/angular-css-modules
Article with the step by step: https://indepth.dev/angular-css-modules/
I hope it will be useful for you.
Related
I am currently working on a Vue.js project where i use the Vue CLI 3 to build components in lib mode like this: vue-cli-service build --no-clean --target lib --name ComponentName.vue. The components can then be used any website if registered in a Vue instance.
However, the website contains it's own stylesheets and the component too. To develop and see the actual styles applied to component i have to pull in these (shared) styles in every component i develop. Therefore they are also in the compiled stylesheets after building the component using the command stated above (vue-cli-service build).
My question: Can i exclude the (shared) styles when building the component? I can't find anything about it in the docs (https://cli.vuejs.org/). If somebody could provide the answer or a (Webpack) workaround that would be much appreciated.
Many thanks in advance!
I am not sure if I understand you correctly but there is an option to have these styles inline in the components itself, which would be much easier for development.
https://cli.vuejs.org/guide/build-targets.html#app
dist/myLib.css:
Extracted CSS file (can be forced into inlined by setting css: { extract: false } in vue.config.js)
I will try to be concise, I must work on a Reactjs project for school project, my task is to take a existing html/css theme and and put it in React components.
But I have a problem since the start, I used CreateReactApp for a clean start and import index.css of the theme.
Create a basic form base on the theme and have this error. (She disapear when I delete index.css)
Error I see
Failed to compile
./src/css/index.css
Module not found: Can't resolve '../images/category-1-bg.jpg' in
'C:\Users\50031\Documents\React-Project-master\src\css'
Structure of the project is that
Structure project
Thanks so much, I already check for an answer but I suck as hell in code and understand nothing.... Sorry
Your images directory is not inside css directory and that is what the error says. This is because somewhere in your index.css you have not assigned correct path for the images. Assign correct paths to the images in your index.css and the app should compile.
Install css-loader so that it will include the image during build time.
I decided to try out WebPack on a new project I'm spinning up today and I'm getting really strange behavior from the sourcemaps. I can't find anything about it in the documentation, nor can I find anyone else having this issue when skimming StackOverflow.
I'm currently looking at the HelloWorld app produced by Vue-CLI's WebPack template -- no changes have been made to the code, the build environment, or anything.
I installed everything and ran it like so:
vue init webpack test && cd test && npm install && npm run dev
Looking at my sourcemaps, I see the following:
This is a hot mess. Why are there three version of HelloWorld.vue and App.vue? Worse yet, each version has a slightly different version of the code and none of them match the original source. The HellowWorld.vue sitting in the root directory does match the original source, but what's it doing down there instead of in the ./src/components folder? Finally, why isn't there a fourth App.vue that has the original source for it?
As far as I can tell this may have something to do with the WebPack loaders. I've never gotten these kinds of issues with any other bundler, though. Below is an example of the exact same steps using the Browserify Vue-CLI template:
No webpack:// schema, only one copy of every file, the files actually contain the original source code (kind of important for source maps), no unexpected (webpack)/buildin or (webpack)-hot-middleware, no . subdirectory,.... just the source code.
I haven't worked with Vue so can't really describe how exactly this is happening but it seems to be related to Vue Loader. Looking at the documentation I did not really find anything that clarifies why it would create three different files for one component. But it does seem logical considering that a .vue file might contain three types of top-level language blocks: <template>, <script>, and <style>.
Also, looking at two of those files you do see a comment at end of each file that suggests it was modified in some way by a Vue loader. Either this
//////////////////
// WEBPACK FOOTER
// ./node_modules/vue-loader/lib/template-compiler
or
//////////////////
// WEBPACK FOOTER
// ./node_modules/vue-style-loader!./node_modules/css-loader
The third file is different but it still does have code that identifies it as being modified by Vue loader. Here is some of that code
function injectStyle (ssrContext) {
if (disposed) return
require("!!vue-style-loader...")
}
/* script */
import __vue_script__ from "!!babel-loader!../../node_modules/vue-loader/..."
/* template */
import __vue_template__ from "!!../../node_modules/vue-loader/..."
/* styles */
var __vue_styles__ = injectStyle
The document also says this:
vue-loader is a loader for Webpack that can transform Vue components written in the following format into a plain JavaScript module:
Which explains why you might not see the same type of behaviour with other bundlers.
Now, This might not be the answer you were looking for but just wanted to share what I had found.
This is actually a feature of webpack.
webpack has HMR (Hot Module Reloading). If you look in your network tab, go ahead and make an update to your HelloWorld.vue file. You'll see a js chunk come thru as well as an updated JSON manifest. Both of these will have a unique hash at the end for each time you make a change to the application. It does this so the browser does not have to do a full reload.
For a better explanation of this I would highly recommend reading through https://webpack.js.org/concepts/hot-module-replacement/
When I work with angular2 code I often need to see the implementation of a class, let's say the Router class.
If I click on the Router type in my IDE WebStorm, e. g. inside the constructor of another class
export class myClass {
constructor(private router: Router) {}
// ...
}
my IDE takes me to the TypeScript definition file router.d.ts inside my node_modules folder. What I want is it to take me to the original router.ts file with the implementation of the router class, not just its definition.
The original .ts file is not included in the node_modules folder structure when you get angular2 from github via the standard package.json suggested in the Angular2 Quickstart. Currently, I have to look up the original code in the official github repo.
Any ideas how to get the .ts files into my node_modules/#angular folder instead of the .d.ts files?
Sadly, it's not possible since no TS files exist. Even if you add them it still not possible since you import real angular paths which always point to the definition files. On top of that the file structure of the project does not correlate to the structure of the import string literals.
Some background and more information
The NPM package does not include .ts files, this is by design from the angular team. Up until some time ago the .ts files were indeed supplied with the NPM package.
The reasoning for removing them is to disable abuse from users accessing private classes and #internal and private APIs which is public methods/properties in the API that are not supposed to be public but must be so other angular internal classes can use them.
We used to see a lot of code samples out there doing things like import { PromiseCompleter } from 'angular2/src/facade/lang'; (before RC0) but this was changed when the project structure had a big structure refactor in RC0. This abuse was wide and it's bad, very bad... For users and for Angular PR.
The Angular project has a complex and robust build process where all of the API is moved from .ts files into d.ts files using an automated process that limits exposure. (public_api_guard)
The end result is d.ts files only.
It's also not possible to clone the git repo and use it since, again, the file structure is way way different so imports will have to change. Most importantly without the build Angular will, most likely, not work.
A solution using a different approach
However, if you debug your app you notice that you reach actual angular core .ts files in the source view of the console, this is because the NPM package comes with source map files that include the whole TS source code. Nice trick they did there.
This is what I use to dig deep into angular, it works quite great and I get a lot from it.
It's not as nice as Goto Declaration but it something...
IMO it's also easier to understand when you step through code...
I'm inspecting this Webpack demo project https://github.com/Foxandxss/GermanWords-ng1-webpack. This project contains in several files this line (features/home/index, features/login/index):
import angular from 'angular';
I don't understand - if 'angular' library will be included several times in result js file because this library exists in several source files? I've looked at webpack config file, but can't understand. Please, can you clear this questions?
It's just to be sure that angular will be available for every module. Imagine you use a feature to be a new standalone site, you will have already the code ready. Always think like every feature is a standalone (handle routes, dependencies, controllers, views etc.).
Webpack will handle the dependencies and inject only once angular, dont worry. Like #thsorens says in comments : "All dependencies in your files needs to be imported where it is used."
Oh and for furthermore, i've found this yeoman generator base on Foxandxss work : https://github.com/Aleksion/generator-angular-webpack-babel
Have fun.