I am looking to use the Facebook Static Analyzer Flow with my Ionic project. I am new to the different package managers as Ionic uses Webpack. Every tutorial I see for Flow indicates to configure Babel to use it, but it does not appear that Ionic uses Babel. Is there an issue configuring Flow with Ionic 3 with Babel?
All the references I have found for Typescript use either Babel or Webpack, which is why I am not sure that the two can work together.
There are two parts to Flow, the flow binary, and the flow preset for Babel.
You write JS with added flow type annotations, but the flow type annotations would not be acceptable to your JS interpretter (node, browser etc) - so the source files have to be transpiled to remove the Flow type information.
Babel is your transpiler, with the appropriate presets and plugins.
Webpack is used ahead of that chain to marshall other resources to get from source to build/distribution code.
Webpack can be configured with the babel-loader plugin so that Babel is run as the packing proceeds.
The babel-preset-flow is used to transpile the type-annotated code to plain JS.
So, Webpack uses Babel, Babel uses Flow preset.
There is also a comment mode for Flow which allows you to use Flow without having to do any transpiling which might also be a solution to your problem if you can't configure the tool stack to your liking.
Related
Has anyone been successful in adding material-components-web into snowpack project?
I have used #snowpack/plugin-sass", it work fine with local .scss files, but when trying to import MDC components with javascript for example (import {MDCRipple} from '#material/ripple'; ), it breaks the sass modules of mdc in node-modules and always gives error like 'dependency not found'.
Also used saas-migrator package and it didn't work with them either.
It seems like a sass version failure, but don't know what is problem because all the examples are based on webpacks.
Could anyone share proper snowpack+#snowpack/plugin-sass+material-components-web configuration with simple example?
I'm trying out some OpenWhisk actions in Swift. For better or worse, almost all of the OpenWhisk documentation is about javascript. When writing actions in javascript, it looks like you can package up code as an npm module and require/import it into any action. With Swift, there's no indication that there's any way to share code. I found one sample project (https://github.com/SwiftOnTheServer/DrinkChooser by the inestimable #rob-allen) which uses the clever trick of pre-processing the source code files before building them:
cat actions/_common.swift actions/myaction.swift > build/myaction.swift
Is there an official way to share code across actions?
Many thanks.
Building Swift binaries locally and creating actions from those binaries will allow you to do this. Swift's package manager will generate multiple executables if you have the correct directory layout.
This example project which uses The Serverless Framework to build and deploy multiple binaries as OpenWhisk actions.
Creating actions from Swift sources files does not support providing multiple sources files for code sharing.
I have flow integrated into a webpack / babel build using flow-babel-webpack-plugin and it works great. Webpack dev server compiles / serves assets in less than a second and if there are flow type errors it prints them out nicely. I'm very happy with that.
The problem begins when I turn on my IDE. In both VSCode and Atom, if I enable any kind of flow support, my webpack / babel build immediately begins to choke. It will take anywhere between 4 and 70 seconds to compile any change. Often it fails and gives multiple flow is still initializing notices and indicates it has tried to start the server over and over.
I suspect that both webpack and the IDE are trying to spin up separate flow servers at the same time and this is causing a conflict. Or they are using the same flow server and this is, for some reason, also a problem. I just can't figure out what to do about it. I have tried pointing at separate binaries with webpack using the global flow and the IDE using the one from node_modules. No dice.
It seems like this must be an extremely common use case - flow + a webpack watcher + any IDE whatsoever.
I'd like to have both my webpack build compile flow code and have my IDE show me syntax errors etc. So far that's been impossible
It looks like that plugin uses its own copy of Flow, from the flow-bin package:
index.js
package.json
If this version is out of sync with what your IDE is starting up, then they will fight -- starting up one version of Flow will kill any Flow server with a different version that is already running in that directory.
If you put flow-bin in your devDependencies (alongside this webpack plugin) and lock it to a specific version, and also set your IDE to use the Flow binary from flow-bin, then it looks like npm will just install the version you specify, and both the plugin and the IDE will be able to use the same Flow version.
Without knowing more specifics about your setup, it's hard to recommend a more concrete solution. You'll have to either make it so both your IDE and this webpack plugin are running the same version of Flow, or stop using either the IDE or the webpack plugin.
I would like to create a test suite which will be run with karma against my app which is using webpack to build itself. I have two entrypoints, app and vendors. These are set up through my webpack.config.js file here. The resulting bundle.js should contain both of these entrypoints in its generated file.
My karma (mocha) tests residing in test/spec/*_spec.js are currently pointing to specific components, via require statements like:
var app = require('../src/scripts/App')
They also utilize react/jsx which seems to be causing problems during the test run where I get jsx errors:
Module parse failed: /Users/dmarr/src/status/test/spec/app_spec.js Line 10: Unexpected token <
You may need an appropriate loader to handle this file type.
I'd like to keep test runs quick as possible as well as fast build times for testing with webpack-dev-server during development by minimizing babel transforms to only where needed.
What do I need to do in karma.conf.js to get my builds working? Here is the karma.conf.js file I'm playing around with.
Note, that I do have this working without breaking out the vendor bundle here: https://github.com/bitwise/status
Thanks for any help,
Dave
In a similar setup, disabling CommonsChunkPlugin (for testing only) worked for me. Give it a shot!
I've just picked up CoffeeScript and I'm struggling to understand the deployment workflow. It seems you constantly have to compile the .coffee files before using them. (Yes, I'm aware that you can have it embedded in the browser, but that's not recommended for production applications).
Does one have to constantly (manually) compile the files before deploying? (For example, if using Eclipse, a simple Ctrl+S saves and deploys the .war/.ear on the local machine's server.) Do we have to change the build scripts (for a central, possible CI server) for deploying .coffee files? Is there anyway to have integrated compiling via the IDEs (Eclipse/Netbeans)
Any ideas/pointers/examples on this? How/what have you used in the past?
I call browserify in my Cakefile to pre-compile and package my CoffeeScript for the browser. For an example of how I call browserify as well as coffeedoc and coffeedoctest take a look at the Cakefile for my Lumenize project.
If you are using express or some other node based server, you can have your CoffeeScript compiled at request time, using tools like NibJS or as described in The Little Book on CoffeeScript (Applications chapter), you can use Stitch. BTW, I highly recommend, The Little Book. The "Compiling" chapter has information about Cake and compiling that might help you.
Yes, you should have a build script. Most CoffeeScript projects use a Cakefile for this; see, for example, 37signals' pow. With a Cakefile, you can just run
cake build
from the command line to run the build task in the Cakefile.
You can run the Cakefile on a CI server, assuming that you have Node and CoffeeScript installed on that server.
Don't deploy the coffee files, use something like "coffee -cwj" to constantly watch and compile the .coffee files into javascript (.js) files and deploy those.
The options are c=compile, w=watch and j=join the files.
See the coffee-script web site for details of the options you can pass in.