Allowing compiled code delivery #2772
Labels
Comments
|
A discussion in discord regarding this, for reference: |
|
Yes. This is blocking me using reason/bucklescript. I don't have that much control over the CI environment (AWS codebuild) and I'd rather not install the Ocaml compiler on every build. My preferred workflow would have the third-party reason in node_modules compile to some other build directory and commit the I think this is related or a duplicate of #2418 |
|
@Khady (sorry having to mention you here, assuming that I tagged the right person XD) |
|
With webpack 3, my config looks like this: const path = require('path');
const slsw = require('serverless-webpack');
module.exports = {
entry: slsw.lib.entries,
resolve: {
extensions: [
'.js',
]
},
output: {
libraryTarget: 'commonjs',
path: path.join(__dirname, '.webpack'),
filename: '[name].js',
},
target: 'node',
externals: {
// Possible drivers for knex - we'll ignore them
// mysql is commented because it is used by our app
'sqlite3': 'sqlite3',
'mariasql': 'mariasql',
'mssql': 'mssql',
// 'mysql': 'mysql',
'mysql2': 'mysql2',
'oracle': 'oracle',
'strong-oracle': 'strong-oracle',
'oracledb': 'oracledb',
'pg': 'pg',
'pg-query-stream': 'pg-query-stream'
}
}; |
|
And I have a full example that is documented here: |
|
Thanks!! |
|
Not sure if it is too late, we will start working on it |
|
Well, I'm since moved to a new company and got to evaluate Reason and BuckleScript again. So this will really help my point. |
|
How is this coming along? |
|
We are moving in this direction (slowly though)
发自我的iPhone
…------------------ Original ------------------
From: Aaron Shafovaloff <[email protected]>
Date: Fri,Aug 16,2019 3:10 AM
To: BuckleScript/bucklescript <[email protected]>
Cc: Hongbo Zhang <[email protected]>, Mention <[email protected]>
Subject: Re: [BuckleScript/bucklescript] Allowing compiled code delivery (#2772)
How is this coming?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
This would be great for deploying to environments like zeit/now |
|
Is this still planned? :) |
|
for people who subscribe this issue, we will make major progress on this issue, stay tuned |
|
It is a long awaited feature request. Landed in master. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi, so this is not exactly a bug, but it is a use case that I think deserve some attention.
Bucklescript is a compile to JS compiler that adds its own JS files to the bundle in the end, unlike TypeScript or Flow that compile "cleanly", without additional dependencies.
Since TS for example do not add any more dependencies, it acts just as a compiler. Technically, one can compile his code locally and deliver the code without Typescript as a dependency.
bs-platformon the other hand have JS files that the code depends upon.As I noted in this previous issue: #2769
It means that currently, you have to deliver the entire compiler with npm to use bucklescript.
But as package dependencies, this is a norm too. to expect local compilation on the target everywhere.
as noted for example in the
bs-jsonpackage with @glennsl rightful comment: glennsl/bs-json#34This basically makes the npm packages of the BS community dynamic by default. npm install is not enough, you must compile locally too to make the JS files available.
This blocks alot of BS use cases -
In environments you just can't install OCaml compiler for various reasons.
In environments it will be wasteful and expensive (Essentially blocking server-less use case altogether)
Installing compiler takes 5~ minutes on CI. Build process is now substantially slower.
@glennsl points on the
bs-jsonissue linked above are valid too.I could only think on one solution for this so far, if the community even agrees a solution is needed..
To enable the option when compiling, to have additional
vendorfiles target, where thebs-platformdependencies, and external packages compiled code dependencies will go to.That way you can compile locally only once, have all the dependencies pre-compiled and ready to run. Reliably, pre-known, and not in any way dependant on the local machine compiler.
The text was updated successfully, but these errors were encountered: