The CLI Vue guide describes how to create a new project.
As of December 2020, this is the way I used to create the Astrea project.
Note: other ways exist in older documentation, but they create different scaffolding - recommend to stick to this one way to avoid having to figure out how other scaffolding and packaging schemes work.
This exemplifies creating a Vue project called throw2:
aleja@CC-Labs-2 MINGW64 ~/Documents/Code/consulting/astrea/scrap $ vue create throw2 Vue CLI v4.5.7 ┌─────────────────────────────────────────┐ │ │ │ New version available 4.5.7 → 4.5.9 │ │ Run npm i -g @vue/cli to update! │ │ │ └─────────────────────────────────────────┘ ? Please pick a preset: Default ([Vue 2] babel, eslint) Vue CLI v4.5.7 ✨ Creating project in C:\Users\aleja\Documents\Code\consulting\astrea\scrap\throw2. � Initializing git repository... ⚙️ Installing CLI plugins. This might take a while...
In the end, it creates scaffolding that looks like this:
However, you are probably missing an important file: vue.config.js, which is not build by default by the vue create command.
vue.config.js
vue create
This file is important for many things. For example, to enable debugging in VS Code and for other things as cited in Stack Overflow on vue.config.js, which cites instructions for manually creating vue.config.js.
For debugging a Vue app in VS Code, instructions are in Debugging Vue in VS Code.
The version is set by the scaffolding used to create the project.
For example, with Vue CLI 4.5.7, it will use Vue 2.6.11 even though Vue 3 is already available.
Vue CLI 4.5.7
Vue 2.6.11
This information is in package.json for your project:
package.json
An issue with externalizing configuration for Vue.js applications is that the “usual” way to do so (Linux/Windows environment variables or command line parameters) are passed to the server, and they would normally not survive to the browser, which runs bundles created by Webpack which are not receiving such O/S environment variables or command line arguments.
To remedy this, Vue.js allows specifying Vue.js environment variables which Webpack will replace by inlining their values wherever they appear in the code. Thus, the bundles run in the browser will involve modified code where environment variable values have been already resolved.
Some of this is explained in Vue CLI environment variables.
GOTCHA: all environment variable names must start with VUE_APP_... - otherwise the Webpack plugins from Vue.js probably would not detect that these are meant as browser level environment variables, and leave them as is instead of inlining their values in the chunk/bundle browser deployable that Webpack produces.
VUE_APP_...
Here is an example that worked for me:
First step is to define your application environment variables in a .env file at the root of your project, as in this example:
.env
Once defined, you can reference this environment variable in your code as in this sample printout:
We illustrate by an example, in which a plugin called finastra_astrea-make is added to Astrea.
finastra_astrea-make
Astrea
The plugin is implemented as an npm local module, where generally we follow the steps for creating an Node.js module except that we never publish the module to an NPM registry in the cloud - instead we install it locally.
First we create a new npm project in the folder where the plugin’s code will exist (which should be a GIT repo):
aleja@CC-Labs-2 MINGW64 ~/Documents/Code/consulting/astrea/makes/finastra_astrea_make (development) $ npm init This utility will walk you through creating a package.json file. It only covers the most common items, and tries to guess sensible defaults. See `npm help init` for definitive documentation on these fields and exactly what they do. Use `npm install <pkg>` afterwards to install a package and save it as a dependency in the package.json file. Press ^C at any time to quit. package name: (finastra_astrea_make) version: (1.0.0) 0.0.1 description: Plugin into the Astrea framework to materialize a Finastra SPA based on Astrea entry point: (index.js) astrea_make.js test command: git repository: keywords: author: Alejandro Hernandez license: (ISC) About to write to C:\Users\aleja\Documents\Code\consulting\astrea\makes\finastra_astrea_make\package.json: { "name": "finastra_astrea_make", "version": "0.0.1", "description": "Plugin into the Astrea framework to materialize a Finastra SPA based on Astrea", "main": "astrea_make.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "author": "Alejandro Hernandez", "license": "ISC" }
This creates the package.json file that defines the plugin as a Node.js project. When you later build, you might have build errors because of a missing linter, in which case you can add it the appropriate linter configuration to the package.json.
Node.js
Here is an example of how the plugin’s package.json might look, with the linter configuration added:
Then you can develop the plugin. In the above example, the entry point for the plugin was configured to be astrea_make.js, so at a minimum the code of the plugin must include such a file so that the plugin can later be entered into as a Node.js module.
astrea_make.js
In our example, this is a toy implementation of astrea_make.js - the key point is that it exports the entry points that plugin consumers would later use:
After that, you locally install the plugin into the project that will use it. This will also ensure that when we change the plugin then the “copy” of the plugin in that was installed in the embedding application also changes (it is just a link).
Here we illustrate with a dummy test project, called pilots, which is totally empty when we start. We install the plugin and then simply write a test for it. The mere act of installing the plugin will create a node_modules folder, if none already exists, which is where the plug is locally installed:
node_modules
aleja@CC-Labs-2 MINGW64 ~/Documents/Code/consulting/astrea/makes/pilots $ npm install --save ./../finastra_astrea_make npm WARN saveError ENOENT: no such file or directory, open 'C:\Users\aleja\Documents\Code\consulting\astrea\makes\pilots\package.json' npm notice created a lockfile as package-lock.json. You should commit this file. npm WARN enoent ENOENT: no such file or directory, open 'C:\Users\aleja\Documents\Code\consulting\astrea\makes\pilots\package.json' npm WARN pilots No description npm WARN pilots No repository field. npm WARN pilots No README data npm WARN pilots No license field. + finastra_astrea_make@0.0.1 added 1 package from 1 contributor and audited 1 package in 0.694s found 0 vulnerabilities aleja@CC-Labs-2 MINGW64 ~/Documents/Code/consulting/astrea/makes/pilots $ ls node_modules package-lock.json aleja@CC-Labs-2 MINGW64 ~/Documents/Code/consulting/astrea/makes/pilots $ ls node_modules/ finastra_astrea_make
For the pilots project to use the plugin, it just needs to invoke the plugin’s entrypoints of interest, as in this example:
pilots
As a test, we can run this test.js to see that the plugin’s logic is correctly invoked by the client app (test.js in this case) that was extended with the plugin:
test.js
aleja@CC-Labs-2 MINGW64 ~/Documents/Code/consulting/astrea/makes/pilots $ node test.js This is a message from the Astrea make testing package FOO from the Astrea make testing package { corporate_products: { asset_class_name: 'Corporate Banking', assets: [ [Object], [Object], [Object], [Object] ] }, nacm_products: { asset_class_name: 'North America Community Markets', assets: [ [Object], [Object], [Object], [Object] ] }, digital_products: { asset_class_name: 'Digital', assets: [ [Object] ] }, payments_products: { asset_class_name: 'Payments', assets: [ [Object], [Object], [Object] ] }, retail_international_products: { asset_class_name: 'Retail International', assets: [ [Object], [Object], [Object] ] }, tcm_products: { asset_class_name: 'Trade & Capital Markets', assets: [ [Object], [Object], [Object] ] }, marketplace_tems_products: { asset_class_name: 'Marketplace & TEMS', assets: [ [Object] ] } }