4 ms·

Was really excited about this until I got to "smart node module". Isn't changing the contents of a package in node_modules going to break any kind of caching, d

Was really excited about this until I got to "smart node module". Isn't changing the contents of a package in node_modules going to break any kind of caching, de-duplicating etc? In my current project we install node_module` ahead of time and bake it into a docker image, it is quite common.

codegladiator 7y ago
Is there any other framework or library using these "smart" node_modules ? I never noticed.
- nikolasburk 7y ago
  I don't believe so, this term was coined by one of our community members and we really liked it and decided to adopt it to distinguish Prisma Client conceptually from "conventional" (for lack of a better term) node modules.
  - eyelidlessness 7y ago
    Was there consideration of using something like schemats[1] and allowing users to specify where they want to store the types for their schema? Storing them in `node_modules` is extremely unidiomatic and probably rules this library out for me even though it's otherwise attractive at first glance. [1]: https://github.com/SweetIQ/schemats https://github.com/SweetIQ/schemats
    - nikolasburk 7y ago
      You can specify where you want to generate Prisma Client yourself, `node_modules` it's just the default. See my response above: > Also note that you can actually generate Prisma Client into a different location [4], so if you prefer not to have it in node_modules, that's totally possible as well. [4] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/generating-prisma-client#specifying-the-target-location-for-prisma-client https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
      - eyelidlessness 7y ago
        That sounds nice. Your link 404s tho. Edit: it did at first, now it's loading. I've seen other 404s just clicking around the docs. It's possible you've got some CDN caching issues?
        nikolasburk 7y ago
        Yeah, we just published the new website today and moved around a ton of stuff. We're still in the process of cleaning things up here and there, feel free to ping me when you find more broken links :) (@nikolasburk on Twitter or Prisma Slack)
  - swyx 7y ago
    hey nikolas! Svelte's Sapper generates its own @sapper modules I believe. https://github.com/sveltejs/sapper/ https://github.com/sveltejs/sapper/
nikolasburk 7y ago
Depending on your deployment environment and workflow, there indeed can be special requirements wrt deployment (also because Prisma Client relies on a "query engine binary" [1] which needs to run as a side-process on the same machine as your application). When deploying, you need to ensure that you're selecting the right build target [2] for the binary. You can find more info in the deployment docs [3]. TLDR: Generally deployment should "just work", but there can be cases when you might have to do some extra configuration to get your app deployed. Also note that you can actually generate Prisma Client into a different location [4], so if you prefer not to have it in node_modules, that's totally possible as well. [1] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/query-engine https://www.prisma.io/docs/reference/tools-and-interfaces/pr... [2] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-schema/generators#binary-targets https://www.prisma.io/docs/reference/tools-and-interfaces/pr... [3] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/deployment https://www.prisma.io/docs/reference/tools-and-interfaces/pr... [4] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/generating-prisma-client#specifying-the-target-location-for-prisma-client https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
- migueloller 7y ago
  Having the option to generate it elsewhere is great, because it does break some pretty big integrity invariants that are assumed by various tools. node_modules shouldn't be changing, specially when there's lockfiles being used.
crubier 7y ago
This is such. A. Stupid. Decision. Indeed. For example, we use yarn pnp in our codebase so I have absolutely no hope that it will ever work with Prisma 2. “Don’t try to be smart” is a very useful mantra for programmers, but Prisma seems to ignore this. But hey I don’t want to use it anyway because what I want is a graphql endpoint not an ORM. We used Prisma 1 and now moved on to graphile.
- nikolasburk 7y ago
  Hey there, thanks a lot for the feedback! As I mentioned in other threads, you can configure the output location for the generated Prisma Client library [1], node_modules is just the default. The reason why we made it the default is because it comes closest to what Node.js developers are used to and therefore fits their workflow and mental model nicely. Also please read this Twitter thread between the lead Yarn maintainer and our CEO [2]. The gist is that we're very open to other approaches but this was the best we've come up with so far after 9 months of experimentation and lots of feedback from the community. This doesn't get easier by the variety of package managers out there and the custom workflows they sometimes employ (e.g. wrt pruning and caching). To put it in the words of our CEO: we'd be more than happy to embrace whatever package manager mechanism would enable this use case "more cleanly". [1] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/generating-prisma-client#specifying-the-target-location-for-prisma-client https://www.prisma.io/docs/reference/tools-and-interfaces/pr... [2] https://twitter.com/FredKSchott/status/1245053210852618246 https://twitter.com/FredKSchott/status/1245053210852618246

codegladiator 7y ago

Is there any other framework or library using these "smart" node_modules ? I never noticed.

nikolasburk 7y ago
I don't believe so, this term was coined by one of our community members and we really liked it and decided to adopt it to distinguish Prisma Client conceptually from "conventional" (for lack of a better term) node modules.
- eyelidlessness 7y ago
  Was there consideration of using something like schemats[1] and allowing users to specify where they want to store the types for their schema? Storing them in `node_modules` is extremely unidiomatic and probably rules this library out for me even though it's otherwise attractive at first glance. [1]: https://github.com/SweetIQ/schemats https://github.com/SweetIQ/schemats
  - nikolasburk 7y ago
    You can specify where you want to generate Prisma Client yourself, `node_modules` it's just the default. See my response above: > Also note that you can actually generate Prisma Client into a different location [4], so if you prefer not to have it in node_modules, that's totally possible as well. [4] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/generating-prisma-client#specifying-the-target-location-for-prisma-client https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
    - eyelidlessness 7y ago
      That sounds nice. Your link 404s tho. Edit: it did at first, now it's loading. I've seen other 404s just clicking around the docs. It's possible you've got some CDN caching issues?
      - nikolasburk 7y ago
        Yeah, we just published the new website today and moved around a ton of stuff. We're still in the process of cleaning things up here and there, feel free to ping me when you find more broken links :) (@nikolasburk on Twitter or Prisma Slack)
- swyx 7y ago
  hey nikolas! Svelte's Sapper generates its own @sapper modules I believe. https://github.com/sveltejs/sapper/ https://github.com/sveltejs/sapper/

nikolasburk 7y ago

Depending on your deployment environment and workflow, there indeed can be special requirements wrt deployment (also because Prisma Client relies on a "query engine binary" [1] which needs to run as a side-process on the same machine as your application). When deploying, you need to ensure that you're selecting the right build target [2] for the binary. You can find more info in the deployment docs [3]. TLDR: Generally deployment should "just work", but there can be cases when you might have to do some extra configuration to get your app deployed. Also note that you can actually generate Prisma Client into a different location [4], so if you prefer not to have it in node_modules, that's totally possible as well. [1] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/query-engine https://www.prisma.io/docs/reference/tools-and-interfaces/pr... [2] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-schema/generators#binary-targets https://www.prisma.io/docs/reference/tools-and-interfaces/pr... [3] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/deployment https://www.prisma.io/docs/reference/tools-and-interfaces/pr... [4] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/generating-prisma-client#specifying-the-target-location-for-prisma-client https://www.prisma.io/docs/reference/tools-and-interfaces/pr...

migueloller 7y ago
Having the option to generate it elsewhere is great, because it does break some pretty big integrity invariants that are assumed by various tools. node_modules shouldn't be changing, specially when there's lockfiles being used.

crubier 7y ago

This is such. A. Stupid. Decision. Indeed. For example, we use yarn pnp in our codebase so I have absolutely no hope that it will ever work with Prisma 2. “Don’t try to be smart” is a very useful mantra for programmers, but Prisma seems to ignore this. But hey I don’t want to use it anyway because what I want is a graphql endpoint not an ORM. We used Prisma 1 and now moved on to graphile.

nikolasburk 7y ago
Hey there, thanks a lot for the feedback! As I mentioned in other threads, you can configure the output location for the generated Prisma Client library [1], node_modules is just the default. The reason why we made it the default is because it comes closest to what Node.js developers are used to and therefore fits their workflow and mental model nicely. Also please read this Twitter thread between the lead Yarn maintainer and our CEO [2]. The gist is that we're very open to other approaches but this was the best we've come up with so far after 9 months of experimentation and lots of feedback from the community. This doesn't get easier by the variety of package managers out there and the custom workflows they sometimes employ (e.g. wrt pruning and caching). To put it in the words of our CEO: we'd be more than happy to embrace whatever package manager mechanism would enable this use case "more cleanly". [1] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/generating-prisma-client#specifying-the-target-location-for-prisma-client https://www.prisma.io/docs/reference/tools-and-interfaces/pr... [2] https://twitter.com/FredKSchott/status/1245053210852618246 https://twitter.com/FredKSchott/status/1245053210852618246