I'm following the workshop provided by aws, https://cdkworkshop.com/20-typescript/30-hello-cdk/300-cdk-watch.html.
When I issue
$ cdk watch
After the command is succeeded, it never returns. I can see that the new function is deployed correctly on the aws console. But it seems like it didn't finish normally.
When I issue
$ cdk deploy --hotswap
I get no error. It deploys and returns cleanly.
Anyone knows or experiences the same?
This is the expected behaviour. "watch mode (cdk deploy --watch, or cdk watch for short) continuously monitors your CDK app's source files and assets for changes and immediately performs a deployment of the specified stacks when a change is detected".
Watch mode is a common CLI idiom. Typescript's tsc --watch, works similarly, for instance, continuously compiling to js as you make changes.
Related
I am using electron-builder to package an application and I'm looking for a way to guard against the following mistake:
My electron app has a main process dependency required in production, but I mistakenly listed it in devDependencies. I don't notice this during development because the module is installed in my development environment.
After building the production version and launching it, an alert dialog will pop-up with an Error: cannot find module stacktrace.
I'm looking for an automated way to catch/prevent this mistake.
What I tried so far:
After building with electron-builder, I have an automated test that launches the production app as a node child_process.spawn and then connects to it using puppeteer. And I have a process.on('uncaughtException') listener in the main process.
Since this error is raised from the require stack, it appears to not get handled by this listener. Also, the error creates an alert dialog box that blocks execution of the spawned process until the box is closed (something I don't know how to do in a CI environment) which means the test hangs and times-out without providing useful feedback.
I'm using electron-builder to package the main process dependencies and vite to bundle the renderer dependencies.
So I'm a cdk and typescipt beginner.
After successfully deploying a couple of stacks I'm not getting the following error with cdk synth: Unexpected token export. Subprocess exited with error 1.
I'm less interested in solving this issue and more interested to where the stack trace is, or any kind of additional info about the error. Doing a --trace or -v does not really provide much helpful info.
Any ideas how I can obtain such information????
What happened behind the scene is that CDK converts to stack into a cloudformation template and saves it into S3 - The S3 bucket created when running cdk bootstrap(More info here).
When you run cdk synth, CDK trying to convert the code ( in your case typescript) into cloudformation stack. this error: Unexpected token export. could be since async call that didn't end, in addition, this error means that your code could not be transferred into cloudformation stack, but it doesn't mean your "cdk" code is broke.
When you run cdk deploy cdk compare the transferred template with the S3 template. And deploy only the diffs.
Update:
Yesterday DevopsStart publish new article about debuuging cdk in vs code.
This might be helpful.
CDK Debugging in VSCode.
I believe the issue is because npx is used to run ts-node under the hood and npx appears to swallow the stack as described here.
One work around is add a try/catch block, e.g.
try {
main()
} catch (e) {
console.log(e)
throw e
}
So I think this is being caused by some javascript (yours or possibly in an imported module) that is using ESM export syntax.
This confused me a little at first because I'm using import/export syntax all over my project however the project is written in typescript which means that it's being compiled to javascript before execution and most likely all of these ESM statements are being emitted in CJS syntax. I however was also using lodash-es because I preferred the import syntax. This module internally uses ESM syntax in javascript and as such this is interpreted directly by the node runtime. Modern versions of node can use ESM syntax however only under specific package configs which mine did not have. My solution was just to remove the offending package however you may be able to go the other direction and configure your package.json such that ESM is enabled in node. This may also require your tsconfig.json to be updated such that the typescript compiler also emits ESM.
https://nodejs.org/api/esm.html
Passing --debug flag helped me.
cdk synth --debug
Not sure how to ask this question but would like to put it here and want to hear some suggestions.
So far, I use "DB_LINK" variable that has mongo database url in my config.json file. My Node app uses this variable to connect to the Mongo. But this DB_LINK also gets checked into git, which we dont want this to happen because we dont want to check in the passwords into git.
in my local development, I use local.json file that has all these configs and not check that file into git (in .gitignore entry). So it is fine making it work in my local dev environment, but the challenge is when Jenkins try to push the code to TEST, it has to pass testcases (it has to run test cases, so that time the DB_LINK value is needed) before deployment happens. so this is when I need this DB_LINK variable be passed from Jenkins.
Here is what I did so far ..
in Jenkins configurations, at the 'predefined parameters' I added DB_LINK=myMongoLink to parameters list.
but this value is not being handed over to my node app. Any suggestions on how to achieve what I am trying to achieve?
Ok. I figured this out. before the change, I used to pass a command from Jenkins to run my test cases like this
npm run test
but now,
DBLink=myDB npm run test
so the DBLink variable from here being handed over to the node app and was able to run the test cases. Before this change,
I used to pass this DBLink=myDB from a config file
Title says it all.
If I understand correctly, the Heroku VM environment provides some built-in binaries and then additional ones can be provided in a custom build pak.
Trial (by building a little test app) and error (by having the build fail) is the only way forward so far. Surely there's a better way.
I have read the Heroku docs and looked in obvious places in the Ruby build pak source. No list.
My immediate aim is to determine if a Rails app that requires GD2 graphics (the gd2-ruby gem) will build without a custom build pak. But the general question of binaries availability comes up again and again.
Run heroku run bash, and get a shell in a plain dyno. Then list all rpms installed by invoking dpkg --get-selections, as for example here: https://askubuntu.com/questions/17823/how-to-list-all-installed-packages or here: http://www.howtogeek.com/howto/linux/show-the-list-of-installed-packages-on-ubuntu-or-debian/
I'd like to know if there is any way to develop continuously with Trigger.io and avoid the forge build step with every file change I want to test in my browser or simulator.
I was faced with the same problem and I've got a working solution that uses watchr and watch to automatically rebuild each time I make a change to a source file. If you are running a "web" version of your app you can make a change to a source file and go directly to your browser and see the effect of your changes fairly quickly depending on how long the build takes.
Prerequisites: Ruby, watchr, Unix 'watch', and a terminal.
gem install watchr.
create a new ruby file for watchr to know what files to monitor and what to do when it sees a change. I named my file 'my_watch.rb': https://gist.github.com/3153167
open two terminals. Terminal 1 will run watchr and Terminal two will run 'forge build ...'.
In terminal 1 run 'watchr my_watch.rb' making sure the path to my_watch.rb is correct and make sure you've edited my_watch.rb according to your setup so that the path inside watch(...) reflects the files to be watched. My example watches all files in the same directory (and beneath) as the my_watch.rb script. You can place my_watch.rb in the 'src' folder of your Trigger.io app if you want to match my example and run watchr my_watch.rb directly from the src folder. Also not the shell command and path in the block need to be updated to reflect your environment. Again, in my example 'my_watch.rb' is inside 'src/' so when a change is detected we go up one directory and call 'forge build'.
I tend to develop actively with the 'web' version of my app so I can just open terminal 2 to my forge project directory and 'forge run web'. When I am testing in simulators and on devices, yes I have to run forge build every time I want to see a change. However, I typically don't have to wait for forge build to finish because watchr kicked off the build as soon as I made a change and it happens pretty quickly.
I know this is not an ideal solution but so far developing new features in the 'web' version first and then implementing in mobile versions has been very smooth for me. I've never needed to kill the 'web' version after a build but I maybe just lucky. As for running build each time you want to test the mobile versions if you are good with your keyboard shortcuts it really isn't bad at all. XCode makes you build and run after changes are made to source code when creating native iOS apps so I don't think Trigger is unique in requiring this build step.
I hope this helps and that my answer isn't too specific to me and my setup.
The build phase makes some changes to your source to enable the forge.* APIs - therefore, trying to just use the raw files in your src directory won't work.
You may be tempted to change files directly in the development directory, but this is a pretty bad idea: we delete those files with impunity when we need to!
We have plans on our medium-term roadmap to add a file-system watcher to start builds automatically when changes have occurred.
In the meantime, I just use forge build && forge run PLATFORM which tends to only take a few seconds...
while not perfect... this works for me.
go into development/web
rm src
link to your root src, ie ln -s ../../src src
copy the all.js from the web/forge and add to your index.html
ie
start nodemon web.js
open in browser.
note you will need to comment out the all.js script tag for non web builds.