Updating Ember.js environment variables do not take effect using in-repo addon config() method on ember serve - ember.js

My goal here is to create an auto-increment build number that updates both on ember build and ember serve. In the end, if I can only use this on build, that's totally ok.
I originally asked this question:
In-repo addon writing public files on build causes endless build loop on serve
In that I was attempting to solve this problem by writing out JSON files. The problem was mostly solved, but not using ember serve.
Instead of doing that, I'm now trying to update the local environment. But this is having a similar problem with ember serve. I've got the build number incrementing fine. I can use the config() method to set custom/dynamic variables in the environment. The problem I'm having is that the even though I can log the change in terminal when config() is called, and I can see it run on serve when files change, I don't see the changes in browser when I output Ember's ENV using ember serve. Here's my addon's methods so far.
Note: the appNumberSetup() function is just reading a local json file in the project root and updating the build number. That's working fine. Anything about pubSettingsFile can be ignored, I won't be using that moving forward.
init(parent, project) {
this._super.init && this._super.init.apply(this, arguments);
// we need to setup env in init() so config() and prebuild()
// will see update immediately
this.settingsFile = path.resolve(this.appDir, this.settingsFileName);
this.addonPubDataPath = path.resolve(this.appDir, 'lib', this.name, 'inc', 'public', 'build-data-output');
this.pubSettingsFile = path.resolve(this.addonPubDataPath, this.pubSettingsFileName);
// this only checks for .env variables and sets defaults
this.dotEnvSetup();
// must set this so prebuild skips processing a build number on build
// else we get build number incremented twice on first run
// then appNumberSetup() disables so subsequent serve preBuild() will run.
this.skipPreBuild = true;
this.appNumberSetup();
},
// this sends our created settings data to ENV.localBuildSettings in app
config(environment, appConfig){
// this 'buildme' is just an experiment
let x = `buildme${this.buildNumber}`;
let r = {
localBuildSettings: this.settings
};
r[`buildme${this.buildNumber}`] = this.buildNumber;
this.dlog("Config ran...");
this.dlog(JSON.stringify(r, null, 4));
return r;
},
preBuild: function(result){
// init() disables preBuild() here, but subsequent builds with serve still
// run appNumberSetup() to update this.settings for env and JSON
if(this.skipPreBuild === true){
this.skipPreBuild = false;
}
else {
// only run here after init runs
this.appNumberSetup();
}
// don't do this... write file makes endless loop on serve
// this.saveSettingsFile(this.pubSettingsFile, this.settings);
},
this.settings is a local variable in addon and it updated on build/serve, the JSON looks like this:
{
"appVersion": 911,
"appBuildNumber": 7117
}
Is there a way to update Ember's ENV with dynamic data? (like a new build number)
The addon config() appears to run on each change in ember serve, and it shows the build number in terminal output. But it looks like that runs after postBuild(). Maybe that's why I don't see the changes. Is there a way to update that environment during preBuild()?

I'm not sure of the specifics but ember-cli-new-version does this. During the build stage they create a VERSION.txt file, might even do what you need already without needing to write it yourself.

Related

Next.js CLI - is it possible to pre-build certain routes when running dev locally?

I'm part of an org with an enterprise app built on Next.js, and as it's grown the local dev experience has been degrading. The main issue is that our pages make several calls to /api routes on load, and those are built lazily when you run yarn dev, so you're always forced to sit and wait in the browser while that happens.
I've been thinking it might be better if we were able to actually pre-build all of the /api routes right away when yarn dev is run, so we'd get a better experience when the browser is opened. I've looked at the CLI docs but it seems the only options for dev are -p (port) and -H (host). I also don't think running yarn build first will work as I assume the build output is quite different between the build and dev commands.
Does anyone know if this is possible? Any help is appreciated, thank you!
I don't believe there's a way to prebuild them, but you can tell Next how long to keep them before discarding and rebuilding. Check out the onDemandEntries docs. We had a similar issue and solved it for a big project about a year ago with this in our next.config.js:
const { PHASE_DEVELOPMENT_SERVER } = require("next/constants")
module.exports = (phase, {}) => {
let devOnDemandEntries = {}
if (phase === PHASE_DEVELOPMENT_SERVER) {
devOnDemandEntries = {
// period (in ms) where the server will keep pages in the buffer
maxInactiveAge: 300 * 1000,
// number of pages that should be kept simultaneously without being disposed
pagesBufferLength: 5,
}
}
return {
onDemandEntries,
...
}
}

Ember build and sourcemaps

My Ember app is actually a child engine. Recently, I observed that the source maps are not working properly in Chrome. So, I have to open the generated engine.js to debug…Instead I want to be able to open the individual source modules/files written in ES6 using Ctrl + P in Chrome Sources and add breakpoints to debug.
I tried both the ways in ember-cli-build.js;
babel: { sourceMaps: ‘inline’ }
sourcemaps: { enabled: true, extensions: [‘js’] }
My question is am I doing something wrong with the above? Does the parent/host app have any impact on the generated source map OR is the child engine configuration for sourcemap totally independent of the parent config ?

Running a request in Postman multiple times with different data only runs once

I am new to Postman and running into a recurrent issue that I can’t figure out.
I am trying to run the same request multiple times using an array of data established on the Pre-request script, however, when I go to the runner the request is only running once, rather than 3 times.
Pre-request script:
var uuids = pm.environment.get(“uuids”);
if(!uuids) {
uuids= [“1eb253c6-8784”, “d3fb3ab3-4c57”, “d3fb3ab3-4c78”];
}
var currentuuid = uuids.shift();
pm.environment.set(“uuid”, currentuuid);
pm.environment.set(“uuids”, uuids);
Tests:
var uuids = pm.environment.get(“uuids”);
if (uuids && uuids.length>0) {
postman.setNextRequest(myurl/?userid={{uuid}});
} else {
postman.setNextRequest();
}
I have looked over regarding documentation and I cannot find what is wrong with my code.
Thanks!
Pre-request script is not a good way to test api with different data. Better use Postman runner for the same.
First, prepare a request with postman with variable data. For e.g
Then click to the Runner tab
Prepare csv file with data
uuids
1eb253c6-8784
d3fb3ab3-4c57
d3fb3ab3-4c78
And provide as data file, and run the sample.
It will allow you run the same api, multiple times with different data types and can check test cases.
You are so close! The issue is that you are not un-setting your environment variable for uuids, so it is an empty list at the start of each run. Simply add
pm.environment.unset("uuids") to your exit statement and it should run all three times. All specify the your next request should stop the execution by setting it to null.
So your new "Tests" will become:
var uuids = pm.environment.get("uuids");
if (uuids && uuids.length>0) {
postman.setNextRequest(myurl/?userid={{uuid}});
} else {
postman.setNextRequest(null);
pm.environment.unset("uuids")
}
It seems as though the Runner tab has been removed now?
For generating 'real' data, I found this video a great help: Creating A Runner in Postman-API Testing
Sending 1000 responses to the db to simulate real usage has saved a lot of time!

react-router-redux - app doesnt re-render after dispatching a push-action

I'm trying to integrate the newest Version of react-router & react-router-redux into sample application from a react-book. But i can't get the example working with routing over react-router-redux push/replace function.
I'm not certain if its a bug or i'm using the functions wrong.
actions/index.js
...
export function dismissVote(history) {
// this changes the history locations an application re-renders
//return () => history.push('/votes');
// this changes the history locations but application doesnt re-render
return dispatch => dispatch(push('/votes'))
}
...
Version used (package.json)
"react-router-dom": "4.1.1"
"react-router-redux": "5.0.0-alpha.6"
App Repository (clone from github)
https://github.com/ap0yuv/voteapp.git
How to reproduce my issue
clone the repo.
cd ./myapp
npm run start:hot && npm start
Launch Application in Browser # localhost:3000/votes/vote_1
Click Button "Vote later"
Expected Behavior
Browser Location is changed to localhost:3000/votes/
AND
The List of all votes (localhost:3000/votes) is visible (VotePage)
Actual Behavior
Browser Location is changed to localhost:3000/votes/
AND
Page of Current Vote (vote_1) is still shown
If i pass the history object to the function to route, the proper page is displayed.
More Information about the code:
src/common/containers/SingleVotePage is the entry point for /votes/vote_1
and passes dismissVote() from src/actions to

ember serve and browser reload results in "cannot GET /foo" with custom Ember.Location

TL;DR: Added custom location type to environment.js then ember serve -> open browser to route /foo -> cannot GET /foo
Followed the instructions at https://www.emberjs.com/api/classes/Ember.Location.html#toc_custom-implementation and copied the code exactly as it appeared into a file called app/locations/history-url-logging.js, added a line to config/environment.js that said:
ENV.locationType = 'history-url-logging';
For reference, the code given in the docs is simply:
import Ember from 'ember';
export default Ember.HistoryLocation.extend({
implementation: 'history-url-logging',
pushState: function (path) {
console.log(path);
this._super.apply(this, arguments);
}
});
I decided to restart the server, did the usual CTRL+C to ember s then did ember s again. I went back to my browser sitting on one of the routes, hit F5, and received the cryptic error:
Cannot GET /contacts
So, after MUCH Googling and trial and error (and posting a previous question here which I just edited with this text you're reading), I discovered that to FIX that error, all I had to do remove the config line ENV.locationType = 'history-url-logging';, restart the server (ember s), and suddenly the app worked fine!
What's even more odd is that if I start the app without that line in environment.js, then once the app is running (and the browser window reloads just fine, etc), then I re-add the line that says ENV.locationType = 'history-url-logging'; (which triggers a live reload), and the app still works fine! (E.g. hitting F5 to reload the page doesn't vie me the "Cannot GET /contacts" (or whatever the route is) error.) And, of course, the console gives me the "console.log" output as expected from the code above.
So, long and short of it, using a custom location totally seems to screw up ember serve - which is really sad and frustrating! Any ideas how to fix this?
Ember built-in server looks at the environment.js locationType property to figure out if it must serve routes after the rootURL path. By default, if the locationType is history it will do it. It uses string matching.
In your case you wrote your own location, inheriting from HistoryLocation therefor the locationType property in the environement.js is now history-url-logging. The built-in server doesn't recognize it as a history based form of location just by the name. It will default to hash location. It doesn't analyze your code.
For this scenario, we have to help the built-in server to understand that the locationType is equivalent to a history location.
You need to add historySupportMiddleware: true in your environment.js file right after the locationType property.