I have a serverless app that is composed by 3 apis. They share a large amount of code. I prepared the whole application in a way that it allows me to boot every api solely or every single one of them at the same time, regarding my needs for that moment. There are some scripts to deploy the apis separately and all in once, as well.
The problem here is the shared code. As it is shared, I needed to copy them through all apis to keep everything running smoothly, because I can't have a folder with that code outside any of the apis. It throws the error I put in the title.
My folder structure is this one:
src
|- api1
|- serverless.yml (for api1)
|- api2
|- serverless.yml (for api2)
|- api3
|-serverless.yml (for api3)
|- common_code_1
|- common_code_2
I registered those 2 folders as paths in my tsconfig.json, but it throws the error anyway. How can I share this code between apis without duplicating it?
If you're using npm, I recommend creating a package.json file in common_code_1 and common_code_2.
Then you can simply require them in the package.json files in api1 with a relative path:
"name": "api1",
"dependencies": {
"common_code_1": "file:../common_code_1",
"common_code_2": "file:../common_code_2",
...
}
Then, Serverless Framework will resolve those packages when packaging your application for deployment.
Related
Is it possible to build or generate only specific pages from a Nuxt project? In other words, a subset of the project.
In example, let's say I have the following pages directory:
pages/
|
|- index.vue
|- about-us.vue
|- pricing.vue
|- moduleA
|
|- index.vue
|- _id.vue
|- moduleB
|
|- index.vue
|- _id.vue
By doing nuxt generate, all pages would be built and the ones that can be pre-render, will be pre-render. Is there a way of only building, for example, everything but moduleB/?
Right now I'm using the nuxt hook generate:extendRoutes to do a list of only the routes that I want to generate as suggested here: https://github.com/nuxt/nuxt.js/issues/2719#issuecomment-362871101 . However, even though only those routes are generated, if one of the routes has a dependency to a module that is not in the list, it will still load that module.
i.e. If everything but moduleB/ is generated, but pricing.vue has a link to moduleB/index.vue, you can still access it by going /pricing => /moduleB
What I want is a subset of the project, so that moduleB/ is not accessible at all without having to fork the project, delete moduleB/, and then build that forked project. Is that possible?
Nuxt generate has an api called exclude that can be used to exclude certain routes from being generated. You can read more from here.
I hope this will solve your problem
We put all products and libraries in one monolithic git repository. Its layout looks like this:
- FooProduct
- BarProduct
- BazLibrary
- 3rd_party
|- fftw
|- msgpack
|- zlib
At current, we are using CMake to control the build. As CMake has separated config, generate and build phase, it would take extremely long time to run if you generate all things together. To avoid this, we give top-level CMakeLists.txt for each part, and referring peer projects by up-level add_subirectory calls. For example:
# FooProduct/CMakeLists.txt
project(FooProduct)
add_subdirectory(../BazLibrary sibling/BazLibrary)
add_subdirectory(../3rd_party/zlib sibling/3rd_party/zlib)
......
Now we are evaluating Bazel, and I immediately got the question: should I only place one single WORKSPACE at top dir of the git repo?
- WORKSPACE
- FooProduct
- BarProduct
- BazLibrary
- 3rd_party
|- fftw
|- msgpack
|- zlib
Or put many WORKSPACE files in each product/library and referring each other using local_repository rule?
- FooProduct
|- WORKSPACE
- BarProduct
|- WORKSPACE
- BazLibrary
|- WORKSPACE
- 3rd_party
|- fftw
|- WORKSPACE
|- msgpack
|- WORKSPACE
|- zlib
|- WORKSPACE
Single workspace or source/build tree by definition only has one (top-level) WORKSPACE. In theory you could place WORKSPACE branches of your tree, but one obvious source of confusion would be, you could not reach project targets when running bazel from directories where another WORKSPACE is along the path between cwd and project root. While you would not really be gaining anything in return.
If you wanted to distribute your configuration across multiple directories (or even submodules), you can add Starlark (.bzl) files with macros ("functions") defining corresponding repository rule targets (external dependencies) anywhere in your tree (such as //3rd_party/...) and load and execute corresponding corresponding definitions in your (project) WORKSPACE file.
But that would be more of an organizational matter (e.g. different people/groups maintaining different dependencies; or just keeping files small), effectively it works (is ultimately evaluated) just like having one big WORKSPACE file.
If the external dependency is referred to as a source and BUILD description. It really does not matter whether it was pulled from entirely different repo or sits in the same tree. It needs to be rebuild, but also gets cached, either way.
I'm trying to build a library (mostly some .vue components) to reuse in different projects (no public npm) with vue-cli-service. Apparently everything its already setup, and I can confirm that the build is fine (js, and css). However, I'm unable to use it in a separate project as an external module because it uses the spread operator (and probably more ES20XX features no yet parsed).
Module parse failed: Unexpected token (2683:8)
You may need an appropriate loader to handle this file type.
| params() {
| const queryParams = {
| ...this.filters,
| ...this.sorting,
| ...this.config.params,
This is the standard command I'm using to build the library
vue-cli-service build --target lib --name [mylibname] ./src/components/index.js
By default the bundle should be already polyfilled but it seems to me that it's not the case.
I've read that I might change the webpack configuration on the project I'm using into, but I'm against parsing the whole node_module folder and also I would love to just have the simplest workflow possible (like import a module and its css).
So my question is, how to polyfill my bundle to be perfectly usable in no matter what Vue project without any hassle ?
Ok, it seems that reinitializing the project with vue-cli without typescript and with separated configuration files instead of into package.json was a good idea, as now is transpiled as needed.
var queryParams = _objectSpread({}, this.filters, {}, this.sorting, {}, this.config.params);
Unfortunately the hidden configuration of vue-cli webpack can't help to see what has changed.
I have multiple services
root/
services/
subscriptions/
users/
shared/
httpUtils.js
database.js
node_modules/
package.json
When I'm running severless locally using serverless-offline my imports work without a problem:
const _ = import('lodash') // module_modules
const database = require('../../shared/database')
However, when I deploy the application won't start because of
error: cannot find module lodash
error: cannot find module ../../shared/database
Does each service need to have its own node_modules dependencies within the service? It would be great if I could just load dependencies from a single node_modules at the root and the shared folder.
What's the standard practice in order to accomplish this for a project with multiple services?
each services gets its own copy of the shared files and node_modules?
private npm package with shared libs?
another packaging tool?
Thanks.
It is recommended that you use a packages.json for each service rather than try to use a single one shared across multiple services. You can get additional details about the use of package.json and the serverless framework here.
I have tried various techniques to share a single node_modules directory, but the solutions are fragile and eventually something will go wrong as I introduce more dependencies and start to version the services.
I do try to share as much as possible across my services, but have determined it isn't worth the effort to share a single node_modules directory.
I am trying to use Aurelia with Symfony backend. Part of our application is generated on the backend (good, old server-side MVC) and part of it should be an SPA. I have started aurelia app from skeleton-typescript (JSPM). Directory structure I am trying to create is as follows.
project/
src/
SomeModule/
SomeOtherModule/
FrontendModule/
build/
src/
app.ts
main.ts
...
index.html
package.json
...
web/
dist/
I have changed the output path in build/paths.js and gulp build correctly places the compiled files in the web/dist. I have also added a gulp task that copies the index.html into the web/.
The biggest problem I have is how to manage the JSPM dependencies. If I configure it to downlad the dependencies into web/jspm_dependencies, the application works when launched with Symfony but I am not able to configure karma unit tests properly (it says for example that it can't find aurelia-polyfills). If I leave the jspm_dependencies in the src/FrontendModule then I have to create a gulp task that copies it to the web/ and it takes a lot more than 10s => unacceptable.
This leds me to the following questions:
What is the suggested directory structure for Aurelia project when I am not going to serve the app from the project's root?
Is there any way to copy only the files needed by the application to the web/ (something like main-bower-files for bower)?
I know I can gulp export the app into the web/, but I want to use the same directory structure during the development, too.
I don't want to use browsersync server in the dev because of multi-nature of the application (SPA part and non-SPA part that has to be served from "real" backend).