Vue CLI 3 target build lib exclude shared styling - javascript

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)

Related

exporting .png files from a library to a React JavaScript project

I'm creating a utility project that will supply React components and resources to my other projects.
I'd like it to include a set of images (mostly .png files for icons) that can then be imported by the child projects.
I can't figure out how to make this work.
I can export the images from the library, and I can see them, name-mangled, in the node_modules of the child project. So, all good so far.
But, import {imgName} from "myLib" does not include the file in the child project's bundle.
It looks to me like my problem is explained by a clue in https://create-react-app.dev/docs/adding-images-fonts-and-files/:
You can import a file right in a JavaScript module. This tells
webpack to include that file in the bundle.
Presumably, CRA is not triggering this webpack behavior in my case, since I'm importing from another module, not from a file.
How can I get things working?
Assume:
I have complete ownership of the library and child projects, so I can change this solution in whatever way works. I just want to have a single common resource for the images.
I don't want to eject my child projects
Ideally, any complexity should be in the library project. The child projects should have minimal complex tooling. (My intent is for this library to be used by a team of other developers, who will want to focus on their own tasks; not on tooling details)
EDIT (ADDED LATER)
Per the comments in the first answer below, I've created a simple example of my problem. See:
Library repo: github.com/deg/media-file-bug-library
Library package: npmjs.com/package/media-file-bug-library
Client repo: github.com/deg/media-file-bug-client
Just pull the client repo and do yarn install and yarn start. This will bring up a little web page that shows the problem:
SCREEN SNAPSHOT:
The Problem is Not in CRA Trigger. Importing Png File like JavaScript Hides a Magic. Here you are importing a Image and Exporting it which then get Processed by bundler and The Bundled Index Actually Exports The name of the Processed Image File Which in Your Case is corss~nAalnlvj.png. That's Why Your Image is Broken but you are able to render name of File, The Case is Same for microbundle or parcel.
How You Can solve it is by separating your assets and components By Placing Images on separate assets folder and place your images there and then add assets to files in your files in package.json
{
.
.
"files": [ "dist", "assets"],
}
And Then Import Image & Using Like This
import React from 'react'
import ico_cross from 'media-file-bug-library-fix/assets/cross.png'
function App() {
return (
<div className="App">
<img src={ico_cross} alt="im"/>
</div>
);
}
For Further Reference Checkout
Here
A Npm Library For Your Fix I Published Npm media-file-bug-library-fix
enter image description here
hey David I found the solution please do check the above screenshot
as in you package just change in index.modern.js
// WebPack doesnt listen as a path it listen
// var cross = "cross~nAalnlvj.png";
// use import rather than simple name as it generate a full absolute path at parent level so that in child level it can be accessible as an Image
import cross from "./cross~nAalnlvj.png"

Does this SASS structure affect React app/component loadtime/performance?

I'm working on my first production-ready React application, and I'm using SASS as a pre-processor for my CSS. One huge benefit I find when styling my React components is being able to break my CSS into separate modules and import the specific modules needed into the corresponding React component.
The more my application grows, the harder it has become to quickly find and update the correct CSS I need while developing. Which leads to my question...
I'm thinking of implementing the following styling, and I'm not sure if it will have any effect on the performance of my app and components:
1 - Continue to separate all CSS into SASS modules
2 - Import all of those modules into a single app.scss file
3 - Import that single app.scss file into all of the components that need styling
This will let me browse a single place - app.scss - for the specific css module I need, and then quickly tell me where I need to go in my app directory to access that file. I see this being beneficial as I could write brief comments in the app.scss about each of the individual modules. That way as the app scales, I'll have documentation about what each css module accomplishes and what components those css modules correspond to.
Thus, my question is will this style of loading so many modules into a single css file and then loading that single css file into each component that needs styling slow down my app/component load time/performance?

How to make CSS class names unreadable with Angular CLI

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.

How to manage custom aspects of a React component (Redux, CSS) whilst distributing via NPM

Question: How are custom Redux containers and CSS normally handled through NPM? The below structure doesn't work well with traditional package distribution platforms such as NPM as I need to edit the custom files such as the Redux container and the CSS in different projects.
Given that I have many components in a custom React component library with the following structure and files:
> Component root dir
> Component.js
> Component.css
> Component_container.js
> Component_custom.css
The Redux container holds store references which change from project
to project
The CSS also holds customisable styling for each project
These components reference other components through their containers
For example:
App.js
=> Component_1_container.js
=> Component_1.js
=> Component_2_container.js
=> Component_2.js
This is great in that it allows me to separate out custom code from the shared code, I can update Component.js and Component.css in many projects without touching the code in the custom files. However the custom container and CSS files can't be managed through NPM.
I can easily see how the CSS could be extracted into a separate folder. The Redux containers are harder because they are referenced by other components as dependencies as in the above structure. Moving them out of NPM and into another project folder would make references between components difficult to manage.
I was thinking of very similar issue and I think you could create a separate module (no matter npm module or just a folder in you're project marked as a module) named ui-kit and all components there will be Redux free, since the client of this components can use other store or work with out any.
Also, you're gonna have folder component or something you have now and your high-level component(App.js) will know only about your component which will know about ui-kit
Structure:
app
-> Components (containers)
-> Component.js
-> Component.css
-> ui-kit (Redux free components)
-> Component.js
-> Component.css
App.js (High-level component)
Having been through quite a guides and example repos, it seems that the best approach to this is to have just a few container elements sitting at a higher level controlling many related components.
I felt it was a decent idea for each component to have individual access to the store with its own container and which could change from project to project, but it is an unmanageable solution.
The main takeaway here is that presentational components should never call container components as a dependency.
Having separated out container and custom style files from the component directory, it is straightforward enough to then create NPM components which contain only the reusable code.
The question is how many containers to use in an app, here is a good summary of how to grouped components against containers which I found useful in answering this question:
http://www.thegreatcodeadventure.com/the-react-plus-redux-container-pattern/

Register both non-angular and angular version of component

I have a javascript project consisting of two js-files
component.js
component.angular.js
component.js contains the actual logic exported to globals, amd or whatever. It can be used as-is if you are not using angular.
component.angular.js wraps the the logic in an angular directive, but requires the logic from component.js.
I would like to register/publish both a non-angular (only need component.js) and a angular (need both component.js and component.angular.js) version of this component in Bower.
Overall question: How to do that?
Questions that might help you figure out why I am confused:
Can you even state that two js-files needs to be used in a bower.json?
I guess registering the repository where the code lives in Bower, it will look for a bower.json file. But I guess I cannot state in a bower.json that you will need both files in case of angular and only one of them in case of non-angular.
Can I have two different bower.json files in the same repository? And register them under two different names in Bower - e.g. under "mycomponent" and "mycomponent-angular".
Do I need two repositories?
Well, I ended up having two repostories. One for sharing the raw component (on bower, npm and meteor) and one for sharing the angular wrapping depending on the raw component (also on bower, npm and meteor).
Raw component: https://github.com/TeletronicsDotAe/infinite-gallery
Angular wrapper: https://github.com/TeletronicsDotAe/infinite-gallery-angular
Do not know if that is the best way, but it works for me.

Categories