lodash supports custom builds with only a subset of the functionality / size. Creating a custom build is a breeze with lodash-cli.
What's the recommended way to take this custom build and integrate it into the project? (using npm / browserify).
Do I create a custom build command that creates the custom build and places it somewhere? (where?)
Is there a canonical way to specify the dependency and integrate into the project?
There are several approaches you can take to use a subset of lodash:
Use the CLI to generate a custom build (a file within your projects codebase) of the features you need
Use npm modules or the lodash modules within your code base (i.e. instead of doing _ = require('lodash'); _.each(...) you would do each = require('lodash/collections/each'))
Use the lodash-modularize tool to create and maintain a custom lodash build for a given project and use lodash as otherwise documented. This is essentially automating the two/three methods above.
Each approach is 100% valid and has their pros and cons
Disclaimer, I'm the author of lodash-modularize
Related
I know that I can use either of the two options below to resolve serverless variables with values from .env.{stage} files.
https://www.serverless.com/plugins/serverless-dotenv-plugin
https://www.serverless.com/framework/docs/environment-variables/
But how would I do if I need my env file to also be per region, e.g. .env.{stage}.{region}?
Unfortunately it's simply not supported by both of those. Consider creating a PR to add this feature to the plugin or Serverless Framework itself.
I believe adding it to Serverless Framework would be great, as this feature is really useful and also the plugin might be abandoned soon, since Serverless Framework provides almost the same features with native useDotEnv: true switch.
If you need this feature quickly, you could always clone the plugin repository, add the feature and then use the plugin from your own copy. You can find out more details in the documentation (search for ./):
https://www.serverless.com/framework/docs/providers/aws/guide/plugins
Could you name each .env file a combination of env+region, and then use that?
Ex:
us-east-1.dev.env
us-east-1.prod.env
...
Then you could deploy with
NODE_ENV=us-east-1.prod, which would give you region + env specific dotenv files.
I want to setup a project with the beta version of vuejs3 that is available now. I would like to compile it into es modules, therefore I cannot use webpack.
Are there any seed projects/guides available that setup vue3 with rollup to emit an es module bundle.
If you have a chance, check out vuejs/vite at https://github.com/vuejs/vite
This server allows you to build single file components. But it also uses rollup, so seeing the code may also be helpful.
the interesting bits are here https://github.com/vuejs/vite/blob/19f8358a47251b35557f4c2bdd8a3ac2b7ef96c0/src/node/build/index.ts#L179
but the important part is the vue-3 friendly rollup plugin "rollup-plugin-vue": "^6.0.0-alpha.8"
I have created this seed project setup for rollup + vue3: https://github.com/gautam1168/rollup-vue-next
For step-by-step creation of this seed project see here: https://gautam1168.com/posts/rollup-vue-3/
Context:
We're creating a new solution consisting of multiple app portals (for lack of a better term), each portal will need to leverage off of a base project that will already include some of my employed proprietary code, as well as any new features pertaining to that portal. Our current app leaves much to be desired, and as we're getting a fresh start, we'd like to go at it the right way. (Thus I'd like to rubberduck my thoughts somewhat)
I've thought of a few possible ways to solve this. Each with it's pro' and cons.
1. GIT Fork A Base Project:
This seems like the most straight forward way. Have a PortalCore
project, then have each project fork it in a downstream only fashion.
Con: If the base changes, we'll need to manually update all of the dependant projects.
Pro: Easier to implement initially, and I believe will reduce some of the other more "laborious" tasks. (Example, single build file that will travel with each new portal with our build requirements.)
The flow would be:
Fork PortalCore > Core will be kept up to date via updating via GIT master
2. Base Project NPM Package:
This seems like an ideal route, as with each deployment the latest version of our base package/project will be installed with each portal.
Con: From my research it seems like we're not able to have a npm package install outside of the npm folder (this pertains to my question). We'll need to share the build file via some other means if we want it to sit in the project root.
Pro: Updates automatically rolled out with the build process
The flow would be:
New Project > Add Portal Core npm > Make custom build task, or grab
from some central repo > Will be kept up to date via npm install >
Gulp Build
3. Combination of the above
Have a git project only containing our base npm modules, & build config. The build can then handle things like moving files to the right location (example. node_modles -> root)
The flow would be:
Fork PortalCore > Core will be kept up to date via npm install > Gulp Build
Questions:
Is there a way to have an npm package (or another package manager) install files to a specific location? (I have checked the npm forum, and this seems like a dead end. But I thought I'd try my luck here)
Are we frankensteining it? We don't want to create a new monster. Does this logic make sense ITO creating something that should be somewhat modular by design, but allows for easier maintenance. How do the big boys do this... if they do this?
The answer to this ended up being much simpler than I expected:
Put all shared services in separate common NPM packages (common components,shared / common services, etc.)
And create a few yeoman generators that assists with initial project
initialisation. (The only drawback is someone needs to maintain them,
should some new core dependency come along... but such is dev life.)
Let's say I create a Rails project and create a default.nix for a nix-shell that will create the development environment for that project via nix-shell .. Naturally, this shell would have whatever dependencies I would need for Ruby on Rails.
Now let's say I also create an AngularJS project and also do the same for that, creating a default.nix to be run via nix-shell ..
Consider, in the future, I may have a project which uses both Angular and Ruby on Rails (hypothetically speaking). Is there a way to take my Angular project's default.nix and my Rails project's default.nix and compose them together without resorting to copy-paste?
Further, let's presume that this project may later require other dependencies. Could I maybe do something along the lines of saving the Rails default.nix as rails-env.nix and the Angular default.nix as angular-env.nix, and then include them in a new default.nix for my Rails-Angular + Extras project so that I can have both the dependencies declared in the rails-env.nix and the angular-env.nix, but also declare additional dependencies beyond those includes, thus maximizing the reusability of my Nix expressions for creating development environments?
A Nix file is just an expression which you can import with import ./path/to/other.nix. You can factor out any expression you like into a separate file and reuse it. It's standard practice to make it a function so you can parametrize it differently for different projects or builds.
Here are some good examples with imports:
http://sandervanderburg.blogspot.ro/2014/07/managing-private-nix-packages-outside.html
And an intro to the Nix expression language, which is rather simple:
https://medium.com/#MrJamesFisher/nix-by-example-a0063a1a4c55
I am new to browserify and its usage is not completely clear to me although the benefits seem to be compelling.
I have a couple of questions and was hoping someone could clarify.
I've seen blog posts about using browserify-shim in the package.json to include third party libraries like jquery and bootstrap. I've also seen posts where tools like gulp are used generate the bundle file. I can't seem to find a good answer on why browserify-shim is required if tools like gulp are able to automate the process. Can someone please shed some light? Why is browserify-shim even required? I feel the gulp solution is a little cleaner although a little more involved. It won't pollute package.json with browserify specific stuff that is a build thing and therefore goes together with gulp (just my personal opinion)
How does one deal with third party libraries that are not in npm and also not public? For example, we purchase a script from a third party. That script is not any common js, but is a regular js file with some dependencies (example, on jquery and underscore).
Browserify lets you take the world of Node and bundle it up for delivery to a browser. It understands Node modules, which define dependencies via CommonJS require statements.
But what if you have some JS code or library that is not defined as a Node module and does not support CommonJS? Enter browserify-shim. It provides a shim wrapper around any script, like your private third party script, so that it can be defined as and used as a Node module that Browserify understands.
The use of browserify-shim is completely orthogonal to how you execute Browserify. There are basically two options there: A) Use Browserify's command line API or B) Use Browserify's JS API.
Using a build tool, like Gulp, implies the second option, since you'd use Browserify's JS API in your Gulp build script (i.e. gulpfile.js). A lot of people prefer the use of Gulp because it has a good ecosystem of plugins that allow you to do a lot more than just call Browserify (e.g. compile CoffeeScript, compile SASS, run JSHint, etc).
So, to answer your specific questions:
Browserify-shim is only required if you have JS code that is not written as a Node/CommonJS module that you need to bundle via Browserify. To do so, you will need to tell browserify-shim which files to shim as modules (and what dependencies they have) in package.json. Note that this is totally unrelated to Gulp; so you will need it whether you use Gulp or not.
What you describe is the perfect use-case of browserify-shim. Put your third party script(s) in your project, configure the files to be modules in package.json per b-shim's documentation, require them in your code, and execute Browserify to bundle them up with your code. You could also bundle them up separately, put them in their own project, etc - however you want to structure it.
A couple things to note:
You can shim just about any JS library this way.
Shimming a JS library to be a Node module changes global scope to be private scope. Hopefully everything in the library is namespaced so that all of its functionality can be exported as a single module, but if it's not, you might have to modify the shimmed code to explicitly attach things to window (which is easy but not recommended) or split the code up into separate files/modules.
Both Browserify and Gulp use streams in their JS API, but Browserify uses native Node streams while Gulp uses Vinyl streams. Since they don't play well together, you'll probably have to use vinyl-source-stream to adapt Gulp to Browserify (e.g. for renaming files in a Browserify pipeline), or use vinyl-transform to adapt Browserify to Gulp (e.g. wrap a Browserify stream for use in a Gulp pipeline).