I've got a private npm package hosted on GitHub. The package is essentially a Vue component and I build it with vue-cli-service build --target lib --name init-map src/main.ts. Here's the main.ts's contents:
import InitMap from "./components/InitMap.vue";
export { InitMap };
I use the package inside my other project, and I develop them both simultaneously. Therefore, I want to link the package: yarn link (inside the package directory), then yarn link #smellyshovel/init-map inside the consuming-project directory.
The problem is that when I run "yarn serve" (i.e. vue-cli-service serve) inside the main project, it freezes on 69%...
... and seems to stay like that forever.
Axios doesn't seem to be a problem to me (even though the message), since 1) everything is working fine without the linked package, 2) it shows a different message sometimes (something bootstrap-vue-related on 58%) though I only saw this other message like once (and not sure what exactly caused the difference).
What am I doing wrong? Why does the serve freezes when using a linked package as a dependency? How do I solve this?
Please, name me any other stuff you would like me to show since I'm not sure what exactly could be related to the issue and therefore haven't included any details that might be of interest.
OK, the problem indeed seems to be related to resolving symlinks, and the solution would be to simply prevent webpack from resolving these symlinks: https://github.com/vuejs/vue-cli/issues/1494#issuecomment-498144990
configureWebpack: {
resolve: {
symlinks: false,
},
}
Related
I'm using the Vue CLI to compile my single page application. I am using Vue Router, Vuex, Axios and Vuetify as imported libraries. I have been using npm run serve during development and that has been fine, however I now want to compile for production.
I have used the command npm run build and the build starts fine with no errors shown, but it seems to never end. I stopped it after half an hour because I thought that was far too long. Can someone point me in the right direction? I assumed it would only take a couple of minutes if that. I'm sure there is some configuration I am missing.
UPDATE
My vue.config.js file contents:
const path = require('path');
module.exports = {
devServer: {
writeToDisk: true,
},
}
When I run npm run build, according to package.json this will run vue-cli-service build
Is it possible to an Expo app example to load a module located in the parent folder AND to see changes in the example app when i rebuild the package (with tsc -w to rebuild on any saved files)?
I precise that the module is not publish on npm yet.
I've already succeed to do that using monorepo architecture with yarn workspaces and expo-yarn-workspaces package.
But what about the case when you don't want to publish your package like a monorepo?
For example, in this repo https://github.com/cuvent/react-native-vision-camera
There is an example RN app in bare workflow and in its package.json there is no mention of the developed package (meaning that it's not installed like a normal dependency).
But in the app src/App.tsx, the package is used like that :
import { Camera, frameRateIncluded, sortFormatsByResolution, filterFormatsByAspectRatio } from 'react-native-vision-camera';
Though, the react-native-vision-camera is used like it's already and normally installed with yarn or npm.
How does it work ?
Thanks.
Finally, I've found something that works for me.
You can find my config for metro if you want here:
https://github.com/grean/react-native-metro-config-app-example
With it, you can access the parent component from the expo app, modify it and immediately see the hot-reload changes.
Create a file metro.config file in your expo root app directory with that code inside:
let config = require('#grean/react-native-metro-config-app-example/index.js');
module.exports = config
For a whole example, you can check this repo out:
https://github.com/grean/react-native-scale-text
In a create-react-app i would like to access some properties of the package.json and show those to the user in the browser. Like the version of the app and the version of some of the dependencies specified in the package.json.
How would I access those properties, without importing and exposing the whole package.json to the client?
Executing npm run build on the create-react-app provides a production bundle in the ./build directory.
Solution 1:
The way it works it does not expose the rest of the package.json content to the production bundle when making a destructured import. (E.g. previous answer from Devchris)
import { dependencies } from './package.json';
Solution 2:
By extending the npm scripts it is possible to read and expose the package.json into the node environment and read it from there at build time (https://create-react-app.dev/docs/adding-custom-environment-variables)
process.env.REACT_APP_DEPENDENCIES
Note: The variable must start with 'REACT_APP_'
What you can do is:
import { version, dependencies } from './package.json';
this will give you all dependencies and the version of your package.json in your js code. Keep in mind that your path to the package.json file might be different.
I am using a third party component (vue-image-lightbox) which currently has a bug. I cloned the repo and made the change and want to deploy it with my app to see if it fixes the issue. To do this I installed yalc.
In the component project (vue-image-lightbox) I ran
npm run build
yalc publish
My understanding is that this places my vue-image-lightbox into the yalc store.
Next, I went to my dependent project and ran
npm uninstall vue-image-lightbox (remove the existing component)
yalc add vue-image-lightbox. This creates
a) .yalc directory with the deployed component
b) adds entry to package.json : "vue-image-lightbox": "file:.yalc/vue-image-lightbox",
run npm install to pick up any dependencies
After this I ran my app and went to the component that uses vue-image-lightbox. In the console I not get the warning
"[Vue warn]: Unknown custom element: - did you register the component correctly? For recursive components, make sure to provide the "name" option."
All of the registration code works without issue with the git installed component. I don't understand why I see this when I try to use yalc.
The component is registered locally with
import LightBox from 'vue-image-lightbox'
components: { LightBox }
I would love to know what is different about the yalc installed component that is causing this issue. Is there a better way to test out patches on third party components other than yalc?
Thanks!
I think this is a config issue related to keeping store in an npm-linked folder.
I made a vue-cli 3 project and got the “counter” example running (from https://github.com/vuejs/vuex/tree/dev/examples/counter)
Works: When I move the store.js to an installed node_modules package (and update its import url) it continues to work.
Breaks: When I move the store.js to an npm linked node_modules package it compiles and dev tools finds the store, but I get a blank screen and console error: Property or method “$store” is not defined on the instance but referenced during render
It also works properly with a linked package if I build the minimized js (npm run build). Is there a config setting I'm missing?
The problem turned out to be that the linked packages had its own node_modules folder. I think that may have resulted in webpack creating 2 instances of Vue and attaching the linked package to the 2nd instance.
Deleting the depended upon package's node modules and letting webpack / vue-cli run at the root level resolved my problem.
I realize this question is ridiculously old, but I ran into this exact issue. As deleting node_modules isn't a valid solution, here's what actually worked.
In the library you're importing into your main app, edit your package.json file.
You want to move Vue to be a peer dependency.
"dependencies": {
"vue": "^3.0.0" // move this
},
Move "vue" here.
"peerDependents": {
"vue": "^3.0.0"
},
This will cause your library to use the instance of Vue utilized by your main vue app. As the accepted answer states, this issue is indeed caused by each package loading its own Vue instance. The issue happens because reactivity is bound to the Vue instance. As each library gets its own instance, this creates a situation where reactivity isn't properly tracked between the instances.
I found the solution to this in the Vuejs git repo at https://github.com/vuejs/vue-cli/issues/4271