How do I produce a node module using dotnet-fable - f#

I have a project that I've created with dotnet fable new -n ProjectName and if I run it with webpack server everything works as expected. However I want to create an Express server. For that I thought I would simply create a node module and then run that. But when I look at the help text from dotnet fable --help I can't find a way to tell fable to just compile the js and to let me chose where those files should be placed. So question how do I tell dotnet-fable to produce js files (and do nothing else).
p.s. using the fable-cli results in a null reference (likely due to the project file structure) which is why I haven't just used that

I just wrestled with the same thing. When using the fable template, dotnet fable npm-run build just builds JS files for me. Try removing the devServer section from webpack.config.js, and changing your "start" script in package.json to say webpack && node bundle.js. (The devServer feature in webpack starts up its own simple express.js backend - something I just learned while building my own fable express app)

Related

How do I set up a new ejabberd server?

I'm trying to figure out how to properly setup an ejabberd project that allows for easy compilation of custom beam files- so far, we've been using an existing project that is cumbersome to manage, and uses erlide as the IDE.
I would like to set up the project in a way that I can use a more helpful IDE like vscode, and somehow streamline the compiling and copying of the beam files and updating the module on the server.
Writing code in Elixir is fine as well- I just want the project to be set up in a way that is dev friendly.
Apologies if the question is too broad, but I'm not exactly sure how else to best phrase it. If you feel like I'm missing something in my current flow, please let me know, as I've basically inherited this project. If there are any clarifications required, let me know as well.
Thanks.
easy compilation of custom beam files
somehow streamline the compiling and copying of the beam files and updating the module on the server.
If the task is about compiling and loading additional modules, a running ejabberd node can compile, load and start additional modules in runtime, see
https://docs.ejabberd.im/developer/extending-ejabberd/modules/#ejabberd-contrib
Usually the modules come from
https://github.com/processone/ejabberd-contrib
but you can tell ejabberd to download other modules from other git repositories, or you can copy modules source code and tell ejabberd to install them. And those modules can be written in Erlang or Elixir. Full example: https://docs.ejabberd.im/developer/extending-ejabberd/elixir/#elixir-module-in-ejabberd-contrib
Basically:
you write the module in your development machine, test it...
when happy with the source code, copy mod_whatever.erl to the production machine, $HOME/.ejabberd-modules/sources/mod_whatever as explained in the example mentioned earlier
run ejabberdctl module_install mod_whatever
In step 2, instead of copying the source code yourself, you can have a git repository just for your module, tell ejabberd the module's git URL, similarly to https://github.com/processone/ejabberd-contrib/tree/master/extra
BTW, for step 3, starting in ejabberd 22.10, there's a page in ejabberd webadmin to install and uninstall those modules (copying the files requires manual administration of course).
I would like to set up the project in a way that I can use a more helpful IDE like vscode
What a coincidence, these days I'm playing with VSCode variants (VSCode, VSCodium, Coder's code-server and Github Codespaces) and how to develop ejabberd using them. This is useful for step 1 that I mentioned earlier (write module and test it). If you are interested in ejabberd + VSCode, tell me.

setting up swagger 3 or OpenAPI in a gradle springboot api

Swagger 3 ? or Open API ..? 3? not sure what they're calling it. There doesn't seem to be a good or easy setup.
I'm looking to add it to my java project
I don't mind manually filling out the config for my controllers and in fact do not want it dynamically config'd
and I don't want a lot of extra fluff with it.
Their github hosts a number of different files and I'm not sure what I do and don't need.
The setup at:
https://github.com/swagger-api/swagger-ui/blob/master/docs/development/setting-up.md
I've run through the setup commands and started locally which returns 2 js files, 1 css, and the swagger.json.
Does anyone know if there's a gradle or maven import / line that I can just plop into my build and get the code I need?
Has anyone setup swagger 3 with just the bare minimum to host the ui page with their controller on a java/springboot app?
any help welcome.
git clone https://github.com/swagger-api/swagger-ui.git
cd swagger-ui
npm install
npm run dev

Automatically switching to minified CSS & JS files in different environments

I am using ASP.Net MVC 5 and also taking advantage of WebEssentials LESS and bundle features.
WebEssentials is setup to create minified css and js files on save. This is a feature I want because I can monitor the output and it lowers the application startup time (not using Asp.Net MVC bundles).
How can I automatically get my app to use the minified version of the files when it is deployed without having to manually change the file names?
So, for example, from:
<link href="somestyles.css" .. >
to:
<link href="somestyles-min.css" .. >
I did read that I could combine WebEssentials and Asp.Net MVC Bundles, providing I disabled the minification option in Asp.Net MVC Bundles. This would then substitute the MIN files in production (web.config [debug="false"]).
Is this my only option or is there a better way to achieve this?
This is definitely not the only way. Another way would be to completely disconnect all Microsoft-based tools (ie bundling, web essentials, etc) and use a Javascript Task Runner. Then the compiling of supersets and pre-processers, minification and whatever other front-end heavy lifting can be in one place. It can also be based on the environment.
So let's address some of your specific concerns.
Task running in the flavor of nodejs and gulp
Download nodejs
After downloading, open up a command prompt and navigate to your project source. For example:
cd "C:\Users\beloud\Documents\Visual Studio 2013\Projects\YourProject"
Initialize a node project by running npm init. This will ask you a bunch of questions about your project. After completion, it will create a file, package.json, which will track your node dependencies and project details.
Now we need to install a few packages. In the command prompt, enter the following commands:
npm install gulp -g
npm install gulp --save-dev
npm install gulp-less --save-dev
npm install gulp-minify-css --save-dev
npm install gulp-if --save-dev
We install gulp globally, so we can use it anywhere (it will add a path for you). Then we install a handful of packages locally to our project that will be doing that actual work (minifying, processing, etc).
Create a file in the same directory as your package.json named gulpfile.js.
Now we need to create our actual tasks. In gulpfile.js, add the following:
//these are the modules that we'll be using in our task
var gulp = require('gulp'),
less = require('gulp-less'),
gulpif = require('gulp-if'),
minifycss = require('gulp-minify-css');
var isDebug = true; // I usually have a config.js file that has this and some handy static paths that I'll be referencing regularly. Then I just require it above.
gulp.task('default', function() {
return gulp.src('Content/less/**/*.less')
.pipe(less())
.pipe(gulpif(isDebug === false, minifycss())) //the first argument is the condition, the second is the method to call if the condition is true
.pipe(gulp.dest('Content/css'));
});
Run gulp in command prompt. That will run the default task. Basically, it will look for any less files in all directories under Content/less, compile them to css, minify them if isDebug is false and output it to Content/css.
Let's make it a little bit more awesome by adding a watch. Add the following to gulpfile.js:
gulp.task('watch', function() {
// Watch .less files
gulp.watch('Content/less/**/*.less', ['default']);
});
Upon running gulp, the task will stay alive until manually terminated. It will watch for changes made to any less file in Content/less and will re-run the task upon saved changes.
Now, you just need to include the name of the css file as it will remain the same, regardless of the environment.
This is a very basic example of using a task runner to achieve what you're trying to do. You can do a whole lot more with nodejs, gulp and everything else I've referenced. I would personally suggest this because, it is way more powerful than the one-off tools you're currently using and Visual Studio 2015 is already heavily relying on this new methodology so you'll most likely have to learn this anyways.
You can learn more by following this really amazing tutorial, Getting started with gulp, by Mark Goodyear.
Grunt (and gulp) support is added in the next Visual studio. This is the javascript developers tools for doing the same thing - bundling for production.
Grunt can create a build version that is not minified for testing but minified for production. I might take some more time and effort but it is the future instead of the MS try they did with bundling. You can already use grunt if you have Node.js installed and be ready for the future.
There is plenty of getting started resource out there. See also Introducing Gulp, Grunt, Bower, and npm support for Visual Studio
Is this my only option or is there a better way to achieve this?
It's not your only option, but since you are working in the realm of MVC it's one of the better options. Since it is designed to be leveraged at different levels, such as individual pages as well as layouts, it will take care of generating the appropriate link.
In general, I would recommend you use a server side bundling framework oriented to MVC so that it can handle the link generation and gives you an intuitive API.
SquishIt is an open-source framework that integrates well with MVC, and is also capable of being switched based on criteria such as a debug flag to generate the original source versus minified versions.
Both SquishIt and the new builtin MVC bundles are fairly similar in terms of what they are meant to accomplish.

How do I change source directory in Dart/Pub config?

I couldn't find answer to this in Dart documentation.
My application's server-side is driven by Spray and by convention static files are stored in /webapp folder. When I try to build Dart project I get following error
C:\work\externals\dart-sdk\bin\pub.bat build --mode=release
Your package must have a "web" directory, or you must specify the source directories.
How can I change it from web to webapp ? My pubspec.yaml looks like this
name: dart_spray_example
description: A sample Dart/Spray application
dependencies:
browser: any
Here is layout of my application right now
You just pass it as an additional argument.
pub build --mode=release webapp
but I would expect troubles doing it this way because only some top-level directory names are compliant with the pub package layout convention.
pub build --mode=release example
would be fine.
It might be easier to just use web as the source directory and move the generated output to webapp. I'm aware that this can cause problems during development but I would expect it to be easier to fix the development setup instead of the build setup.
Using frameworks like Angular and Polymer which make heavy use of transformers have a strong dependency on the package layout convention.

Trigger.io continuous development

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.

Resources