In serverless.yml file, how can I include the modules from parent folder?
package:
include:
- ../node_modules/**
but the packaged zip file doesn't include the dependencies from parent node_modules folder. I have tried the plugin: https://www.npmjs.com/package/serverless-plugin-include-dependencies but it still doesn't work. None of dependencies from parent folder is packaged.
How can I change the dependencies folder directory when packaging my application? I also want to apply excluding devDependencies logic for the parent folder.
I'd suggest to package your functions individually in some side script & then run the serverless deploy.
Then you can easily fine-tune your packaging process and include the node_modules from your parent, excluding the dev dependencies.
package:
individually: true
functions:
sample:
package:
artifact: ../functions/sample/deploy/sample.zip
Another small benefit on this is, if you only want to update some function you can explicitly just repackage that one and run the serverless deploy much faster.
Related
I want to setup the bazel build system to build a monorepo with multiple JavaScript packages with the new rules_js rule set. The documentation of rules_js says that it supports "nested npm packages in a monorepo" via "workspaces", but I don't understand how to wire everything up so that:
each package in the monorepo can have different external dependencies
packages in the monorepo can also depend on each other
I tried using #npm//$DEPENDENCY in the deps of rules like js_library to refer to my npm dependencies (like with the older rules_nodejs ruleset), but I just get errors about non-existing targets.
TL;DR
Set up a pnpm workspace and use npm_link_all_packages multiple times to set up separate node_modules folders in your bin tree. Then refer to the dependencies in these node_modules folders by :node_modules/$DEPENDENCY in your deps.
How does rules_js create node_modules folders?
rules_js uses the npm_link_all_packages rule to set up node_modules folders based on a pnpm-lock.yaml lockfile. This is similar to the pnpm install command of the pnpm package manager. The difference is that pnpm install creates the node_modules folders in the source tree and npm_link_all_packages creates them in the bin tree.
Since you want that each package can have different external dependencies, they each need to have their own node_modules. pnpm supports a single lock file for multiple packages if you set up a pnpm workspace. The resulting lock file can be used by rules_js to set up a Bazel workspace with multiple packages that each get their own node_modules folder in the bin tree. The npm_link_all_packages rule will automatically set up the correct node_modules folder based on the Bazel package name and the pnpm-lock.yaml.
So you have to set up a pnpm workspace and use npm_link_all_packages multiple times to set up separate node_modules folders in your bin tree.
How exactly do I set this up?
To achieve this, you can put the following pieces in your workspace root:
pnpm-workspace.yaml to configure the list of pnpm workspace packages
pnpm-lock.yaml to record how all all direct and indirect npm dependencies are resolved
WORKSPACE.bazel to setup rules_js
package.json to avoid confusing pnpm, and in case you want global scripts or settings for your IDE or similar
BUILD.bazel to create the virtual store with npm_link_all_packages
And in each pnpm workspace package $PACKAGE you put:
$PACKAGE/package.json to configure the direct npm dependencies of $PACKAGE
$PACKAGE/BUILD.bazel to create the node_modules folder in the bin tree with npm_link_all_packages, and for your js_library or similar
So every pnpm workspace package is also a bazel package (since it has a BUILD.bazel).
How can I refer to my npm dependencies in deps?
In the deps of js_library and similar, you can point to the dependencies in the node_modules folders generated by npm_link_all_packages. Typically, the js_library is in the same Bazel package as the npm_link_all_package, so you can just use :node_modules/$DEPENDENCY. If the js_library is in a sub-package of $PACKAGE, you can use //$PACKAGE:node_modules/$DEPENDENCY instead. Then in your JavaScript files, you can import from "$DEPENDENCY" or require("$DEPENDENCY"). This will work out at runtime because the node_modules folder will be at an appropriate place in the runfiles for node to find it.
How can the packages in my workspace refer to each other?
If you want one of your packages $PACKAGE to depend on another one of your packages $OTHER, you put a "$OTHER": "workspace:*" into the $PACKAGE/package.json as usual with pnpm. You also have to make sure that the default target of $OTHER (for example, //some/path/to/other:other) is an npm_package rule. Then you can use :node_modules/$OTHER or //$PACKAGE:node_modules/$OTHER in the deps of a js_library or similar to refer to $OTHER just like you would refer to an npm dependency.
How can I create the pnpm-lock.yaml?
Note that this is a working pnpm setup with some additional BUILD.bazel files, so you can:
use pnpm install --lockfile-only to create the pnpm-lock.yaml
use pnpm install to create the pnpm-lock.yaml and also create node_modules folders in the source tree. These folders are not needed for rules_js but can be helpful for your IDE.
I've been trying to get a bazel monorepo with typescript to work. I have a couple of requirements in mind.
I should be able to import local packages using #myworkspace/ instead of ../../../ and so on, without needing Bazel. This is mostly so I get autocomplete while I'm writing.
The #myworkspace/ package should be the same during development and build time but only Bazel-managed dependencies should be resolved on imports when running sandboxed. Just so I know if I've messed up the name of the package in the js_library rule.
There should only be one lock file for the whole project. All dependencies should be located at root/node_modules.
It should be possible to individually deploy node packages i.e. #myworkspace/myCloudFunction.
It should be possible to include local dependencies in packages that will deployed.
I'm new to Bazel and it seems like it requires some mentality changes when coming from the NPM ecosystem. After googling, I've managed to find something that works for points 1 and 2 (But I might be wrong). I've published the playground repo at https://github.com/vitorelourenco/bazelmono-ts (pretty much a copy from https://github.com/lokshunhung/bazel-ts-monorepo with some ideas I took from https://github.com/angular/angular)
My questions about points 3 and 4:
Say I want the lib Lodash available on package #myworkspace/cloudFunction that will be deployed to Google Cloud Functions. If I install Lodash in the #myworkspace/cloudFunction folder, then Lodash will be added to package.json but I'll have a second node_modules folder and a second yarn.lock file, I don't want that. But if I install it in root/, then Lodash will not be added to the dependencies listed on package.json located at #myworkspace/cloudFunction, and when I deploy it, it won't install. Is there a smart way to handle this issue?
Point 5 is very similar. Ideally, the final Bazel output would have the local dependencies bundled in and ready to use but I can't seem to figure out a way to do it yet. I've tried adding a pkg_npm rule to //packages/app in the playgroup repo but couldn't get it to include //packages/common in it.
I am trying to use Bower to manage client side dependencies from a Java/JSP server side application.
It works and I can access client side libraries resolved via "bower install" as described in bower.json.
However, lots of unnecessary files are added to "bower_components" as declared by the dependencies used (tests, docs, examples, etc).
Q: Can I manually specify filters to include/exclude files from each dependency I declare in bower.json?
If this is not possible, it sounds like i need to resolve "bower install"'s output outside the webapp directory and create a separate (maven/grunt) copy task to create the js lib files structure I want - sounds tedious.
You can use bower-installer which allows you to copy only the files you want by specifying filters to include/exclude files from each dependency in bower.json
Does anyone know why Dart Editor won't allow me to edit files located inside the packages folder? I originally had my library class files outside of that folder, but I thought the right way to do it was to put my library under that folder, so I did it and now I can't modify the files.
Everything in packages/ is (usually) a symlink to a possibly shared copy of a package, so if you edited a file in packages/ you'd be editing it for all your projects, which might be very not what you want.
If you'd like to edit multiple packages together, the best way to do it is to specify a dependency override that uses a path source, like so:
name: my_package
dependency_overrides:
my_other_package:
path: /Users/me/dart/my_other_package
This way any other dependency on that package will also load it from the specified path and pub won't complain that you have different sources for the same package. Then you can open both projects separately in the editor and the my_package will see the changes in my_other_package as you edit.
When I create a sub folder in a Dart Project in Dart Editor, immediately a package subfolder is created inside this sub folder. I have not read anywhere that sub folders have a special meaning for the project structure, but it appears they do. Anybody knows more?
The package subfolder holds symlinks to your Pub packages. You can read more about Pub and Pub packages at http://pub.dartlang.org/doc/.
When you start a non-web project, the editor will automatically create package directories in your bin/ and test/ directories (but not in your lib/ directory). If you create a web project, a package directory is also created in the web/ folder.
If you add a Pub dependency in the pubspec.yaml file and run pub install, your will see that the package folders will contain symlinks to the Pub package you just installed. If you are using Dart Editor, pub install will automatically run once you modify your pubspec,yaml file.
If you create a subfolder inside any directory that contains one of these auto-generated package folders, the subfolder will get its own package directory. This way, you will have access to your Pub packages no matter how deeply you nest your code in a directory.
Shailen's answer is correct. I wanted to add a bit more, as the title of this question is "What relevance to folders have in a Dart project?"
Dart is designed to be very web friendly. Because there is no load path or classpath on the web, Dart apps must run without requiring an installation or pre-configuration of a local environment.
The only way you can link one file to another in Dart is via a URI. These URIs can be file URIs, and they can be relative. That means file A.dart can point to file B.dart via an absolute or relative path.
So, to answer you question, there is nothing special about a folder layout for Dart applications. The app will run as long as your Dart file can reference its dependencies via the same kind of linking rules that exist on the web (think <a href="" or <link src="").
However, pub (the Dart dependency manager) does make a few assumptions about package and application layout. If certain conventions are followed, pub can manage symlinks for you so that it's easier to reference 3rd party dependencies. Do you need to use pub? Nope, you can manually copy files around or manually manage symlinks. But pub certainly does make it easier to use packages, given the constraints of Dart's design (no load path, no classpath).