I have a monorepo setup. It looks something like this:
project
node_modules
packages
my-first-project
prisma
schema.prisma
my-second-project
prisma
schema.prisma
So both projects (my-first-project and my-second-project) have #prisma/client installed and get there dependencies from the upper node_modules folder.
The thing is that whenever i change something in my schema.prisma file (e.g. in my-first-project) and run npx prisma migrate dev --name whatever it generates all the types and stuff and puts it in the upper node_modules folder. this leads to "type not found" errors on the other project (e.g. my-second-project).
Is there a way to tell npm to keep some dependencies in a separate node_modules folder inside each project?
You could configure a custom output path to specify the location at which PrismaClient should be generated.
Example:
generator client {
provider = "prisma-client-js"
output = "../src/generated/client"
}
And you should be able to import PrismaClient like this:
import { PrismaClient } from './generated/client'
By generating PrismaClient outside of node_modules should solve your issue.
Related
I'm looking to rename a package in a yarn workspaces monorepo when publishing that package.
The project structure looks something like:
package.json (a)
core
log
package.json (b)
services
...
The root package.json (a) uses the org #companyA in its name and the log package.json (b) has a name of #companyA/log. This can be imported into other services within the monorepo by importing it like:
import { log } from '#companyA/log';
and that works great. The problem is that #companyA isn't what we would like to publish this package to. Instead we would like to use #companyB. Is there a way to easily change the package.json name when publishing? Can Lerna do something like this?
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
Using NPM Workspaces, I'm sharing one package (components) with others (webapp1 and webapp2). Something like this:
root
apps
webapp1
webapp2
packages
components
Everything is working well, but everything inside components, include source code in the src folder is being shared. Since components' compiled output folder is dist, I'd like to only share that folder. This is how it looks in the root node_modules:
The problem is that when I need to import in webapp1 or webapp2, my import path has to include the dist folder. Here's the intellisense that I get from VS Code:
And this is how I import in webapp1 and webapp2:
import Center from '#mycompany/components/dist/Center'
While everything works, how can I set up my NPM Workspaces so that only the contents of the dist folder is shared in its root?
I've tried NPM's files and .npmignore inside the components folder to ignore everything except for the dist folder, but that doesn't seem to work. The main property in package.json for components is also set to point to dist/index.js:
"main": "dist/index.js"
Interestingly, if I want to import dist/index.js file, I can do it without dist:
import foo from '#mycompany/components'
...however, importing anything other than dist/index.js requires dist to be included in the path.
You should treat the packages folder as a collection of dist folders in your use case.
In this scenario, you would move your packages/components/src folder somewhere else in your project and then build to packages/components instead of packages/components/dist
root
apps
webapp1
webapp2
packages
components
src
components
I have a similar setup in this tooling monorepo I created
An alternative to #nicksaroba's approach, if you don't want to restructure your project layout, you can just setup an alias:
// apps/webapp/webpack.config.js
module.exports = {
// ...
resolve: {
alias: {
"components": "#mycompany/components/dist/"
}
},
// ...
};
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 working on a vue project that needs to use another private vue project as a dependency. This other private project is a vue plugin.
I have found how to tell yarn to fetch a package on a private gitlab repository by adding the following line in package.json:
"dependencies": {
"myPackage": "git+https://{token-name}:{token}#gitlab.com/path/to/repo.git#someTag"
}
This works well, and the content of my repo is downloaded in my node_modules. However, here comes my problem :
In this repo, the actual vue plugin is not at the root, it's under a subfolder of the repo, meaning the index.js at the root of the repo is not the one from my plugin (and I guess it is the one yarn will be using).
I have a custom yarn deploy script that compiles my plugin into one JS file and put it in a dist folder, however the dist folder is not versioned. I can use the gitlab CI to generate it, but still i'm pretty sure yarn won't use what is inside the dist folder.
My (broad) question is : how can I use the tools at my disposition (yarn, gitlab-ci) to be able to use my private gitlab repository as a vue-plugin for one of my other project ?
You would tell other packages how to use your packages by using the properties of your package.json. For instance, the main declaration
{
main: 'dist/index.js'
}
This tells node how to resolve your module from your package.
so require('my-vue-plugin') or import MyVuePlugin from 'my-vue-plugin' would resolve to node_modules/my-vue-plugin/dist/index.js, for example.
As far as versioning is concerned -- you don't version the file, or the folder. You version through the version property of your package.json and, in your case, through GIT by using git tag -a v(major).(minor).(patch).
The version that you tag should match the version that you specify in package.json.
I would recommend reading more about semantic versioning and creating a script (like VueJS) to auto-increment your package, version and publish.