I am working on a project that uses Vue + Tailwind inside a WP plugin for a site that use a tailwind theme generates all the tailwind classes I need.
The issue I am running into is when I load the CSS for my plugin I'm getting some really strange conflicts which I have boiled down to having two tailwind style sheets loaded at the same time.
Unfortunately there are some npm packages I am using that have their own styles and so just omitting the style sheet all together isn't an option.
So my question is there a way to just rollup tailwind separately so I can omit that file if necessary?
Here is an excerpt from my current vite config:
rollupOptions: {
output: {
assetFileNames: 'project-[name].[ext]',
chunkFileNames: 'project-[name].[ext]',
entryFileNames: 'project-[name].js',
},
},
Related
I upgraded my app to Angular cli ^11.0.2 recently, from then my HTML and SCSS changes are not compiled on save even when ng serve is running. I have to save the respective ts file to get the html changes compile. I saw a related issue on Github with no proper solution(Here). Is this because of ivy engine ? or Did I miss any update on any particular npm package?
This seemed to happen due to default Ivy engine configuration with Angular 11.
I disabled the enableIvy flag in tsconfig.json file like this :
"angularCompilerOptions": { "enableIvy": false, "allowEmptyCodegenFiles": true }
A friend suggested that AOT with ivy configuration must be avoided in dev environment to avoid this kind of issues.
When writing custom components is it better to publish the .vue file directly or to publish a compiled version using webpack/other-bundling-tool ?
Bonus: Is there an official document regarding conventions to follow when publishing custom components?
EDIT: What are the pros and cons of either method?
I've published a few open source projects and from experience I can say that it's better to publish your code - or rather, set the main entry point - as a compiled distributable for a few reasons:
Firstly, by outputting a UMD module you are creating a distributable that works across all environments (webpack, browserify, CDN, AMD) and it's as simple as adding the following to your webpack config:
output: {
...
library: 'MyPackageName',
libraryTarget: 'umd',
umdNamedDefine: true
},
Secondly, most developers using webpack will exclude babel-loader from compiling scripts in their node_modules folder by doing something like:
{
test: /\.js$/,
loader: 'babel-loader',
exclude: /node_modules/
}
So, if developers need to compile your code themselves and you have anything in your project that is not a .vue file that uses ES2015 (e.g. a mixin) then you would need to tell developers to apply babel-loader to your project folder in their webpack config.
As for browserifydevelopers having to compile your project, you would need to add vueify and babelify as transforms to package.json (they actually can't set this up themselves) and tell those developers that those are dependencies and get them to set up an appropriate .babelrc file.
All that setup can be a nightmare for devs, many will have little knowledge about their build process, so won't know about excludes, they won't know about transforms, they will just get a bunch of errors and either remove your package or create issues on your repo.
And that's just for the two most common build processes, you will still probably want a CDN and you will still want to allow those using AMD modules to use your package, so a UMD module is the way to go.
That said, you should still distribute the .vue files themselves, which will also allow devs to compile your project if they have advanced configuration requirements.
My application has a directory structure more or less like this:
src-program/ - contains frontend code including package.json and webpack.config.js
src-server/ - contains backend code including a different package.json and .babelrc
shared/foo.js - is JavaScript code that is needed by both the frontend and the backend
All code uses ES2015 syntax and thus is transpiled using Babel.
For the frontend the "transpilation" is done during the Webpack build by using the babel-loader.
For the backend it is done on-the-fly by babel-register.
shared/foo.js requires other modules, that are found in the package.json files of both the frontend and the backend.
Due to how NodeJS/Webpack resolve modules, the shared module isn't found normally.
For Webpack I solved this in a somewhat hacky way using this configuration:
resolve: {
root: __dirname,
fallback: [
__dirname + "/../shared",
__dirname + "/node_modules"
],
extensions: ['', '.js', '.jsx']
},
The first fallback makes sure that the "shared" module is resolved and the second fallback makes sure that modules required by the shared module are still resolved to the frontend node_modules directory.
This allows including the shared module as simple as this:
import * as foo from 'foo';
However, I'm having difficulties to make the backend (ie. NodeJS) resolve the shared module the same way.
I tried with app-module-path, which makes foo.js resolve, but then the file is either not processed by Babel or additional Babel modules like transform-runtime (indirectly needed by foo.js) cannot be resolved since they reside in src-server/node_modules...
I could probably work around the problem by pre-transpiling the code instead of using babe-register but it all doesn't feel right anyway.
So, what is a good way to share code between a Webpack build and the NodeJS server process?
Can you package the shared module up as an npm package (even a package just residing on your filesystem)? Then your src-program and src-server projects can add it as a dependency in their package.json, and it will get copied into their respective node_modules folders.
See: how to specify local modules as npm package dependencies
I want to publish an angular 2 component on NPM. This component use css which refer to some fonts. As far as publishing .ts files I can do that. But I'm lost concerning the css and the fonts.
I have :
despotic-turtle.component.ts
despotic-turtle.component.css
fonts/font.ttf .svg ...
and I have in my css this:
#font-face {
font-family: 'despotic-turtle';
src: url('despotic-turtle/fonts/font.eot?ggipqk');
/* ....*/
}
I can't leave the css and fonts as is, so what can be done ?
css, fonts and html will be included in your npm publish.
The issue you'll encounter will be that the referenced css will not be found unless you add moduleId in #Component:
#Component({
moduleId: module.id
})
Note that you'll have to compile using commonjs to make this work.
Also, you shouldn't publish the .ts files to npm, the only files you should publish are index.js and your-component.js + your-component.css + your-component.html, .d.ts files and font files.
Keep in mind that npm is used to publish transpilled files only, when you import a library, you should not have to compile it (check #angular libraries, there's no ts in their libraries).
I noticed that Bootstrap and Normalize.css both have a "style" field in their package.json.
Why do they have this? If I had to guess, it's to allow users to import the defined stylesheet as easily as doing require('bootstrap'), but that doesn't seem to be the case.
From Techwraith's pull request that added it to Bootstrap:
Many modules in npm are starting to expose their css entry files in
their package.json files. This allows tools like npm-css,
rework-npm, and npm-less to import bootstrap from the
node_modules directory. [...]
It's actually not written anywhere but in the code for these modules
right now. We're hoping to get this standardized at some point, but
we've all reached this convention separately, so I'm inclined to just
go with it. [...]
If you want to read about this style of css development, I wrote a
thing:
http://techwraith.com/your-css-needs-a-dependency-graph-too/
There's also support in other tools, such as the browserify plugin parcelify:
Add css to your npm modules consumed with browserify.
Just add a style key to your package.json to specify the package's css file(s). [...]
Parcelify will concatenate all the css files in the modules on which
main.js depends -- in this case just myModule.css -- in the order
of the js dependency graph, and write the output to bundle.css.