The documentation of sails (http://sailsjs.org/#/documentation/concepts/Deployment) says:
"Configure the 'production' environment so that all of your css/js gets bundled up, and the internal servers are switched into the appropriate environment (requires linker)"
I thought the linker folder is not used anymore in sails v0.10.(sails.js v0.10 create new project --linker not working Gruntfile.js not used):
"Sails v0.10 no longer uses the linker folder--it was just causing confusion."
If these two quotes are not a paradoxon I would love to hear why.
Can somebody explain that step of deployment above ("Configure the 'production' environment..requires linker")?
When I was deploying our Sails JS application, all I had to do was to set the environment variable NODE_ENV as "production":
export NODE_ENV="production"
I was using forever for keeping the server up, using the command:
forever start app.js --prod
The server then starts in production environment. Before starting, it automatically bundles up CSS and JS files into production.css and production.js respectively.
Related
I've been experimenting with single-spa for a while, and understand the basics of the developer experience. Create a parcel, yarn start on a unique port, add the reference to the import map declaration, and so on. The challenge with this is that as my root-config accrues more and more modules managing ports and import-maps starts to get tedious. What I want is to publish these modules to a central repository and load them from there (e.g., http://someserver.com/repository/moduleA/myorg-modulea.js, etc.).
I was recently introduced to localstack and started thinking maybe a local S3 bucket would serve for this. I have a configuration where builds (yarn build) are automatically published to an s3 bucket running on localstack. But when I try to load the root config index.html from the bucket I get the following JS error:
Unable to resolve bare specifier '#myorg/root-config'
I can access the JS files for each parcel and the root-config just fine via curl, so I suppose this would be a problem with any http server used in the same way. I can flip the root config to use the standard webpack-dev-server instead (on port 9000) and it works okay. So I'm guessing there's a difference between how a production build resolves these modules vs. the local build.
Has anyone tried something like this and got it working?
I had a similar issue that I got to work with http-server by adding each child .js file to a sub-folder in the root-config directory and launching the web server at the root-config directory level.
"imports": {
"#myorg/root-config": "http://someserver.com/root-config.js",
"#myorg/moduleA": "http://someserver.com/modules/moduleA/myorg-modulea.js",
"#myorg/moduleB": "http://someserver.com/modules/moduleB/myorg-moduleb.js",
"#myorg/moduleC": "http://someserver.com/modules/moduleC/myorg-modulec.js",
}
Note: By default, Single-SPA has an "isLocal" check before the current import mappings. You'll need to remove this if using a production build or it won't load the correct mappings.
<% if (isLocal) { %>
In my case, I was using localhost instead of someserver so I could navigate into the 'repository' folder and run npx http-server to get everything to run correctly.
I was hung up on this for a little while so hopefully this leads you in the right direction.
For the record, after trying several approaches to hosting a repository as described above, I found the unresolved bare specifier problem went away. So I have to chalk that up as just not having the right URL in the import map. Measure twice, cut once.
I have a landing page (some.html) pointing to bundle.js . Under the chrome debugger I do see all my files getting loaded properly but still I get errors in the code like 'this' is undefined etc .
Please note :
I don't have node / npm / webpack installed
I am not running webpack-dev-server running on this server
What is the proper way to deploy / refer a bundle.js file ?
Do I need to install webpack globally on this server ?
I need to know is it possible to just get the functionality of my SPA through a bundle.js being pointed from index.html provided that bundle.js was generated using a webpack on my dev-machine ?
Seems like yes through an index.html we can point to a bundled js if all the functionality is client side and we can get the desired functionality. My reactApp was broken because it the underlying the page (old application) was supporting prototype.js and therefore react's internal functions had issues. Once I removed reference to prototype - my application is working in that old container –
There are 2 to Environments config on /config/env/
development.js and production.js
You can run production config with: sails lift --prod
development runs by default: sails lift
how to create staging environment config like /config/env/staging.js
and run with: sails lift --staging
The --prod argument is built-in to the Sails CLI; there's no mechanism for adding new arguments to that currently. But you can get the same effect using the NODE_ENV environment variable:
linux & mac:
export NODE_ENV=staging sails lift
windows:
set NODE_ENV=production
It is extremely easy in sails 0.11. Now you can just add subfolder to you config/env directory and sails engine will interpret it as new environment.
In your case you just need to create folder config/env/staging, put there all needed configuration files and start your application with
NODE_ENV=staging sails lift
Migration guide for sails 0.11 you can find in documentation.
When running ember build --environment staging I get a build error. In config/environment.js I have a condition looking for staging so I can change the baseUrl to our staging services. But when I try and build with the environment set I get the following error:
You must pass a file to 'EmberApp::import'. For directories specify them to the constructor under the 'trees' option.
Is this a problem with ember-cli or do I need to declare my environment in my Brocfile somehow?
Since Ember currently has issues with custom environments, try using shell variables for modifying behaviour inside single Ember production environment.
If you call ember like DEPLOY_ENV=staging ember build --environment=production then you will be able to access DEPLOY_ENV shall variable inside all JS files via process.env.DEPLOY_ENV and modify their behaviour accordingly.
I personally like decoupling deploy environment from application environment, cause it allows to have a staging server which is just like production.
I have database migrations (with sqlalchemy-migrate) working well in my dev environment. However, I'm a little stumped about how to integrate this into my deployment process.
I'd like to use fabric to execute the manage.py file on the remote server but I'm not sure what to use for the repository value in this file. Referring to both 'appname/migrations' and '/usr/local/pylons/appname/env/lib/python2.6/site-packages/appname-05.egg/appname/migrations/'
both fail with a migrate.versioning.exceptions.InvalidRepositoryError
Does anyone have a fabfile and manage.py that plays nicely with sqlalchemy-migrate?
What I did was to generate a manage.py file per the sqlalchemy-migrations docs. In there I hacked it up to load our config information which includes the db auth info. In our case it's a Pylons app so it reads the proper Pylons config.ini file.
http://readthedocs.org/docs/sqlalchemy-migrate/en/latest/versioning.html#project-management-script
Then the fabric commands all interact with the manage.py file vs using the Python API directly. Since everything, from the SA-Migrate manage.py through the app itself I don't run into any sort of path issues like you mention.
Not sure this is a 'exact' fix but maybe helps.