In my project, I want to use SystemJS to import a certain CodeMirror addon (xml-fold) from cdnjs.
However, that addon references main CodeMirror js through ../../lib/codemirror. This is resolved as https://cdnjs.cloudflare.com/ajax/libs/codemirror/4.2.0/lib/codemirror, which is incorrect — should be https://cdnjs.cloudflare.com/ajax/libs/codemirror/4.2.0/codemirror.js.
I tried to map wrong URL to the correct one, but it does not seem to be picked up — see below (error in browser console):
SystemJS.config({
map: { 'https://cdnjs.cloudflare.com/ajax/libs/codemirror/4.2.0/lib/codemirror': 'https://cdnjs.cloudflare.com/ajax/libs/codemirror/4.2.0/codemirror.js' }
});
// in actual project I import it through a dependency, but the problem is the same
SystemJS.import('https://cdnjs.cloudflare.com/ajax/libs/codemirror/4.2.0/addon/fold/xml-fold.js');
<script src="https://cdnjs.cloudflare.com/ajax/libs/systemjs/0.19.42/system.js"></script>
Error in console:
system.js:4 GET https://cdnjs.cloudflare.com/ajax/libs/codemirror/4.2.0/lib/codemirror 403
What's the right way to map it?
It's possible to define a package for codemirror in SystemJS configuration and remap lib/codemirror to codemirror.js using package-local map setting:
SystemJS.config({
map: {
'codemirror': 'https://cdnjs.cloudflare.com/ajax/libs/codemirror/4.2.0'
},
packages: {
'codemirror': {
map: {'./lib/codemirror': './codemirror.js'}
}
}
});
This config should be enough to turn this import
SystemJS.import('codemirror/addon/fold/xml-fold');
into this url
https://cdnjs.cloudflare.com/ajax/libs/codemirror/4.2.0/addon/fold/xml-fold.js'
Then, relative path ../../lib/codemirror referenced from it will stay in the same package and will be remapped to ./codemirror.js. (I checked with current SystemJS version - 0.19.42)
You might also want to add
main: 'codemirror.js'
to codemirror package config to be able to import codemirror itself as
SystemJS.import('codemirror');
if you need to do that.
Related
New to pnpm, and trying to get my head around some of the basics. But can't find a lot of documentation around it (which often means that it's either very simple, or I'm doing it wrong...).
I have set up a basic pnpm monorepo with an apps and packages folder by basically creating the monorepo folder, running pnpm init and tweaking the result a bit. I got:
package.json
{
"name": "#myorg/root",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [],
"author": "",
"license": "ISC"
}
pnpm-workspace.yaml
packages:
- "packages/**"
- "apps/**"
.npmrc
shamefully-hoist=true
Notes:
I did not create an index.js, as I have no idea what to put in there..
I know that I can run/build the various apps from the root folder by adding pnpm run dev with a filter to the scripts section, I've not yet gotten around to setting that up, but I believe it's not critical to running the monorepo. (?)
In the apps folder I've already created some Vue3 apps (this works fine). And now I'd like to move some of the Vue components used there into the packages folder of the monorepo, so I can reuse them in the various apps. This is where i'm getting stuck in the sand...
I'm not entirely sure how much scaffolding you're supposed to add to these shared components. Is each one an entire Vue-project by themselves? (I'm guessing yes), and then, how to specify in that project what parts to export?
I have created the folder "y-theme-select" in the "packages" folder, and ran pnpm init and pnpm add vue on it. Now lets say I want to add the following component (let's keep it very simple):
y-theme-select.vue
<template>
<div>
Hello world!
</div>
</template>
Where do I store it? (eg. packages\y-theme-select\src\y-theme-select.vue?)
How do I export it? (clueless)
How do I import it in a shared project (I recon something like "#myorg/y-theme-select": "1.0.0" in the dependencies section of the package.json?)
How to use Vuetify components in here?
Nb. for completeness sake, found two related questions:
Multiple Vue apps, shared components in a monorepo (unanswered, and doesn't specify pnpm monorepo)
How to create my own component library based on Vuetify
First off, the reason it's not documented at pnpm is that it's, except for a few properties, not a PNPM concern.
Secondly, what I found is that reusable components all share a few basic principles, but other than that can vary fairly wildly in setup.
Thirdly, this answer works. But has a few issues, as described at the end of the answer.
I also want to mention the excellent video by "How To Create A Vue.js Plugin Component" by Erik Hanchett, which laid a foundation to this answer.
UPDATE: I stopped building components. As you add functionality to them there's always some new weird issue. Now that scoped CSS turned out to not work, I've changed direction. Here is a super-simple low-tech solution to creating a library of components in this pnpm monorepo:
import YSwitchLang from "/../../packages/common-vtfy/src/components/YSwitchLang.vue"
Just reference the packages folder from within your apps project. (Fingers crossed I won't run into anything new, but so-far so-good.) The instructions below are still valid, but in this scenario you only need step I.
I. Initialization of the project
I'm creating a package that will hold a few generic and similar Vuetify components, so I will call it "common-vtfy". This project will use Vite+Rollup as bundlers. I also use the rollup-plugin-typescript2 package to create the typescript definitions. You can simply leave out vuetify package if your component doesn't depend on it.
cd packages
pnpm create vue#latest
-> common-vtfy
-> Typescript
-> ESLint
cd common-vtfy
echo auto-install-peers = true > .npmrc
pnpm add -D vuetify rollup-plugin-typescript2
pnpm install
In package.json:
prefix the package name with your monorepo name, like so: "name": "#myorg/common-vtfy".
Move "vue": "^3.2.45" entry to devDependencies (not a biggie to leave it here, because we externalize it as well in the build section of vite.config.ts)
Add peerDependencies (not sure if this is needed, but probably won't hurt):
"peerDependencies": {
"vue": "~3.x",
"vuetify": "~3.x"
}
At this point you could run pnpm dev, and see an otherwise empty Vue project, which has way more stuff than we'll be requiring, so go ahead and delete:
public\favicon.ico
src\assets\logo.*
src\components*
Not sure if we could/should delete the css files from src\assets as well. #TBD.
II. Build component
Now we create the components, and setup App.vue to see the results:
YSwitchTheme.vue
<script setup lang="ts"></script>
<template>
<div>
Hello, I'm YSwitchTheme <v-chip>Vuetify Test</v-chip>
</div>
</template>
And similarly for YSwitchLang.vue
App.vue
<script setup lang="ts">
import YSwitchTheme from "./components/YSwitchTheme.vue" // not required if using the vue plugin system
</script>
<template>
<div>
<YSwitchTheme/>
</div>
</template>
III. Create the plugin
Create two files:
src\components\index.ts
export {default as YSwitchLang} from "./YSwitchLang.vue"
export {default as YSwitchTheme} from "./YSwitchTheme.vue"
I believe that this "registers" the components, but the details are not exactly clear to me.
src\CommonVtfyPlugin.ts
The plugin entry file. More information: https://vuejs.org/guide/reusability/plugins.html#writing-a-plugin
I have tried to export the components both as a plugin, and as a individually importable components, which does not require the user to load it as a plugin. However, this did not end up working, so I've commented out that last bit. The plugin must be imported using the Vue plugin system (more on that later)
import type { App } from "vue"
import { YSwitchLang, YSwitchTheme } from "./components"
// Export as plugin
export default {
install: (app: App) => {
app.component("YSwitchLang", YSwitchLang)
app.component("YSwitchTheme", YSwitchTheme)
}
}
// Export as individually importable components
// export { YSwitchLang, YSwitchTheme }
IV. "Local" testing/usage demonstration
To use the plugin we add it to our main.ts, and this is something we can do in this same project. The resulting code is the same as you would use when you are importing it later in your other projects.
main.ts
Add import:
import CommonVtfyPlugin from './CommonVtfyPlugin'
If you're using Vuetify, then also add:
// Vuetify
import 'vuetify/styles'
import { createVuetify } from 'vuetify'
import * as components from 'vuetify/components'
import * as directives from 'vuetify/directives'
const vuetify = createVuetify({
components,
directives,
})
And add the .use clause, in the following manner:
const app = createApp(App)
app.use(vuetify).use(CommonVtfyPlugin)
app.mount('#app')
Now in App.vue, comment out the import statements.
V. Build it
Here we're going to use rollup-plugin-typescript2 to generate the typescript files.
vite.config.ts
Add to the imports:
import vuetify from "vite-plugin-vuetify"
import typeScript2 from "rollup-plugin-typescript2"
Add to the plugins:
vuetify({
autoImport: true,
}),
typeScript2({
check: false,
include: ["src/components/*.vue"],
tsconfigOverride: {
compilerOptions: {
sourceMap: true,
declaration: true,
declarationMap: true,
}
},
exclude: [
"vite.config.ts"
]
})
Add a new section build to the defineConfig:
build: {
cssCodeSplit: false,
lib: {
entry: "./src/CommonVtfyPlugin.ts",
formats: ["es", "cjs"],
name: "CommonVtfyPlugin",
fileName: format => (format == "es" ? "index.js" : "index.cjs"),
},
rollupOptions: {
external: ["vue"],
output: {
globals: {
vue: "Vue"
}
}
}
},
Now you're ready to build it by running pnpm build.
Wrap it up by updating package.json, adding four properties:
"type": "module",
"exports": {
".": "./dist/index.js"
},
"types": "./dist/index.d.ts",
"files": [
"dist"
],
One issue the I've not yet figured out is how to generate a single index.d.ts declarations file. For now I just create the following file by hand in the dist folder. Inspired by the Vuetify project, I have not yet figured out why/how this works.
index.d.ts
declare module '#myorg/common-vtfy' {
import { VueConstructor } from 'vue'
const YSWitchLang: VueConstructor
const YSWitchTheme: VueConstructor
export {
YSWitchLang,
YSWitchTheme
}
}
VI. Use it!
Go back to a project that wants to use these components and add them to the project using pnpm add #myorg/common-vtfy (replace myorg with the name of your monorepo). You should see a new dependency in the package.json file that reads something like "#myorg/common-vtfy": "workspace:^1.0.0".
main.ts or plugins\index.ts (wherever you load your plugins)
Import the components:
import YSwitchTheme from '#myorg/common-vtfy'
import YSwitchLang from '#myorg/common-vtfy'
I was expecting to be able to import the modules using a {}-style import, but this doesn't work. I think this means that we're not correctly exporting the components from the plugin. See issues section.
import { YSwitchTheme, YSwitchLang} from '#myorg/common-vtfy'
And finally, to use the plugin, do:
app.use(YSwitchTheme)
app.use(YSwitchLang)
VII. Updating
At some point you're going to make changes to the component.
Component: Make the changes
Component: pnpm build
Component: Recreate index.d.ts
Application: pnpm update #myorg/common-vtfy
Open issues
Scoped CSS is ignored. I've tried all kinds of different rollup settings.
Confirm that peerDepencies is either a good thing or useless.
I've not been able to figure out how to generate a single index.d.ts typescript declaration file.
Pnpm monorepo update
I think you should run the pnpm update on the whole repo. But haven't dived into that yet.
I will attempt to update and further refine this answer as I gain understanding, and/or when usefull comments are posted here.
Barrel/index files seem to create issues when used with next.js. It doesn't seem established if it's purely a webpack issue or both webpack and next.js
According to this issue tree shaking stops working if we use barrel files. I also created a small repo where I have an issue with an index file. Not sure if it's a tree shaking issue.
Steps to reproduce the issue:
npm install
npm run dev
in browser, visit http://localhost:3000/about-pro, expect to see blank page with errors or warnings in browser's console
go to server's console(where you run npm run dev)
see an error of sort "Module not found: Can't resolve 'fs'" (1) (2) (3)
1- this comes from the await serialize in getAboutPageData file. Which itself is only called within getStaticProps
2 - googling for this issue, you'll find solutions such as modifying next.config.js file. It still doesn't work. Feel free to uncomment the next.config.js file and see for yourself
3 - to "solve" the issue, go to about-pro.tsx, in the imports, import AboutPage from its own file instead of from the barrel/index file
If I only import getAboutPageData from the barrel/index file, then it works fine. But as soon as I import e.g. AboutPage from it, it starts throwing unrelated issues.
Can I continue using barrel/index files with next.js and if yes, is there a simple and intuitive way to do that?
The issue is not in the barrel files themselves but in the library that you're using combined with barrel files.
If you take a look at the readme file https://github.com/hashicorp/next-mdx-remote#examples you can find a warning:
IMPORTANT: Be very careful about putting any mdx-remote code into a separate "utilities" file. Doing so will likely cause issues with nextjs' code splitting abilities - it must be able to cleanly determine what is used only on the server side and what should be left in the client bundle. If you put mdx-remote code into an external utilities file and something is broken, remove it and start from the simple example above before filing an issue.
So in order to make your code work you need to remove the export of getAboutPageData from your barrel file, like this:
export { default as AboutPage } from './AboutPage';
// export { default as getAboutPageData } from './getAboutPageData';
and move the code that uses the library inside the about-pro.tsx file.
import { AboutPage } from '../modules/about';
import { serialize } from 'next-mdx-remote/serialize';
const AboutPro = (props) => {
return <AboutPage {...props} />;
};
export const getStaticProps = async () => {
const serializedContent = await serialize(`# Header1`);
const data = serializedContent;
return { props: {} };
};
export default AboutPro;
I think the issue is that the modules imported in barrel files are executed both client and server side. Probably removing side effects from the barrel file could solve the issue, but I don't know enough about Next.js to be able to do it correctly.
I have an Angular 2 application in which i wish to use wrapbootstrap. I do however have a problem with the fonts (bootstrap, font-awesome, google) as i do not know how to implement them.
When using the css file for wrapbootstrap is says it cannot find font awesome:
"Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8000/fonts/font-awesome/fontawesome-webfont.woff2?v=4.4.0"
I cannot make sense of this as i can see the missing file(s) in resources in the chrome console on that exact address.
The font files are currently in a folder vi the following relative path from the css (application.css) file using them:
Which fits the required path in the css file:
I hope someone out there can provide some guidance as i am lost.
Thanks in advance
Solved
the problem was apparently the location of my fonts folder.
my file structure are as follows:
and i had firstly added the fonts/ relative to where the application.css file was. It had to be located in the root of my app (src)
Adding fonts installed with package manager is quite often a task. For instance, using font-awesome or any other similar library is a typical task one will need.
For this purpose, you can go through the following steps:
In tools/config/project.config.ts:
...
export class ProjectConfig extends SeedConfig {
PROJECT_TASKS_DIR = join(process.cwd(), this.TOOLS_DIR, 'tasks', 'project');
FONTS_DEST = `${this.APP_DEST}/fonts`;
FONTS_SRC = [
'node_modules/bootstrap/dist/fonts/**'
];
...
Create a file tools/tasks/project/build.fonts.ts:
import * as gulp from 'gulp';
import Config from '../../config';
export = () => {
return gulp.src(Config.FONTS_SRC)
.pipe(gulp.dest(Config.FONTS_DEST));
};
In gulpfile.ts (or in seed.tasks.json for newer versions of the Seed)
// Build dev.
gulp.task('build.dev', done =>
runSequence('clean.dev',
'tslint',
'build.assets.dev',
'build.fonts', // Added task;
'build.js.dev',
'build.index.dev',
done));
// Build prod.
gulp.task('build.prod', done =>
runSequence('clean.prod',
'tslint',
'build.assets.prod',
'build.fonts', // Added task;
'build.html_css.prod',
'build.js.prod',
'build.bundles',
'build.bundles.app',
'build.index.prod',
done));
// Build test.
gulp.task('build.test', done =>
runSequence('clean.dev',
'tslint',
'build.assets.dev',
'build.fonts', // Added task;
'build.js.test',
'build.index.dev',
done));
src
Hi there I have been forced to come here due to every resource out there on the topic is very poor and incomplete.
Not only on the babel site but every single post out there is not complete and informative enough.
I tried to reach out at the babel forum and no replies.
I am trying to convert my prototype libraries to Es6 and convert to the most leanest possible code. So no bloaty duplicated generated code and if possible no bloaty requirejs and whatever browserify generates.
I have tried to make a project with grunt and babel directly, configure the external-helpers plugin according to the babel documentation.
It fails to include the relevant helper code and fails to include the import module code altogether.
ie a babel config like
{
options: {
sourceMap: false,
presets: ['es2015'],
"plugins": ["external-helpers"]
},
dist: {
files: {
'build/<%= package.name %>.js': ['src/<%= package.name %>.js']
}
}
}
The main project file has an import like
import Button from './ui/buttons/Button';
The module code looks like this as if the export is placed underneath extra code is generated for that.
export default class ShareButton {}
produces an output like this
Object.defineProperty(exports, "__esModule", {
value: true
});
require('babel-core/external-helpers');
var _Button = require('./ui/buttons/Button');
var _Button2 = babelHelpers.interopRequireDefault(_Button);
No source of the module or the helper object is included.
I searched hard for how to deal with external-helpers and it suggests it has to be imported into a separate file ie something like this to generate only the helper functions needed
babel-external-helpers -l createClass > src/helpers.js
But any resource regards to this fails to go as far as to how to import that into the project.
If I use the transform-runtime plugin, it produces a massive polyfill that cannot be disabled so a bug and not so useful for what I need.
"plugins": [
["transform-runtime", { "polyfill": false, "regenerator": false }]
]
If I use browserify / babelify it makes a royal mess and duplicates code still.
A config like
{
options: {
"transform": [["babelify", {
"presets": ["es2015"],
"plugins": ["external-helpers"],
sourceMap: false
}]]
},
dist: {
files: {
'build/<%= package.name %>.js': ['src/<%= package.name %>.js']
}
}
}
Produces code like this still with the external helper missing and duplicated code not relevant to the helper. ie
Object.defineProperty(exports, "__esModule", {
value: true
});
Is within every module in the generated file.
If I export the classes like this at the bottom of every file
export default class {}
Duplicated code is generated like
var _class = function _class() {
babelHelpers.classCallCheck(this, _class);
};
exports.default = _class;
In terms of filesize that doesn't include bloaty wrapping code like
},{}],2:[function(require,module,exports){
It seems concatting all the prototype classes files together to bundle in one file is the winner still.
So trying to port the library but keep it similar and bundle it together into one file.
Hopefully this is concise enough and there is a simple solution.
FYI browsers do not understand tabs and 4 spaces. I had to edit this post in my editor to get the code blocks working ! It would be nice to have a markup like other places like "```" ?
Let me know thanks.
I'm using rollup with babel now. Rollup produces a clean output as umd mode. Browserify is really bloaty in itself.
There is just a problem with polyfills being converted. I have to concat external ones in like for WeakMap.
I had a problem trying to use the generated Iterator and finding a polyfill for that so I have to code loops a particular way it doesn't generate Iterators.
The polyfill generation in babel is still too bloaty and crazy. It's pretty terrible. So I concat in minified polyfills that are very small and it's used globally.
I was running into something very similar. Was tired of trying to do it the "right way" and ended up just creating https://www.npmjs.com/package/grunt-babel-helpers which simply manipulates the string output.
I write Sass and use grunt-pleeease to inline #includes etc.
Unfortunately pleeease inlines its source map and ignores the existing one.
The source map file from sass is in the same folder as the css I pass to pleeease (main.css and main.css.map)
Is there a way to tell pleeease to use the existing source map and extend it?
I've also run into this problem. Currently, the pleeease grunt task doesn't write out the external source map even if you select the correct options. You can edit the task to make it do this anyway. I've submitted a pull request to the project on GitHub for this fix.
Note that I still had to specify the in and out options (pleeease gets the location of the original source map from the css file's sourcemap comment; you can specify this manually also using the prev option for sourcemaps, just note that you have to set that option to the contents of the sourcemap file, not the path of the sourcemap file--grunt.file.read() will be of use there):
pleeease: {
dist: {
options: {
in: 'build/styles/styles.css',
out: 'public/styles/styles.min.css',
sourcemaps: {
map: {
inline: false,
sourcesContent: true
}
}
},
files: {
'public/styles/styles.min.css': 'build/styles/styles.css'
}
}
},
Until this fix is implemented into the master branch and published on NPM, you can use the GitHub address of my pull request branch in your package.json to get the fix (please note that I will eventually remove this branch if my pull request is accepted or the fix is achieved in some other way):
"grunt-pleeease": "zeorin/grunt-pleeease#sourcemap-external",