falcor
falcor copied to clipboard
Dev mode assertions
Currently it is very to learn the software because if you do anything wrong you get no feedback whatsoever. We should add assertions to the build that is not minified so that we can give helpful error messages whenever possible, including things like invalid paths, and expected but not found items in the JSONG,
How do you think we should tackle this? Easiest way seems to be reintroducing sweet.js as an intermediate step in the build process to compile in/out the asserts depending on the build mode.
No strong opinion on implementation here. If sweet is easy, I say we use it. @Ktrott any objections?
Not sure Satyen's github handle but I'd be surprised used if webpack or browserify didn't allow you to compile code in/out based on build configuration. Not opposed to sweet if that's the way to do it, just question if our existing tools don't already have this support which would keep the stack simpler and improve build time.
On Apr 11, 2015, at 2:20 PM, jhusain [email protected] wrote:
No strong opinion on implementation here. If sweet is easy, I say we use it. @Ktrott https://github.com/Ktrott any objections?
— Reply to this email directly or view it on GitHub https://github.com/Netflix/falcor/issues/81#issuecomment-91927924.
@sdesai
JH
On Apr 11, 2015, at 2:39 PM, Kim Trott [email protected] wrote:
Not sure Satyen's github handle but I'd be surprised used if webpack or browserify didn't allow you to compile code in/out based on build configuration. Not opposed to sweet if that's the way to do it, just question if our existing tools don't already have this support which would keep the stack simpler and improve build time.
On Apr 11, 2015, at 2:20 PM, jhusain [email protected] wrote:
No strong opinion on implementation here. If sweet is easy, I say we use it. @Ktrott https://github.com/Ktrott any objections?
— Reply to this email directly or view it on GitHub https://github.com/Netflix/falcor/issues/81#issuecomment-91927924. — Reply to this email directly or view it on GitHub.
I don't think Browserify/Webpack handles this (outside of their domain), but I'd be surprised if there wasn't an existing solution available around Uglify or the build pipeline tools (gulp plugins etc) to handle this - This is stripping out code during minification right?
Also, curious - shouldn't even't the minified version be providing logging feedback, and the user can decide if they "want it in your face", or log it somewhere.
I think the only thing we should be stripping from the build are developer debugging statements. warns/errors should still be maintained shouldn't they?
On Sat, Apr 11, 2015 at 4:46 PM, jhusain [email protected] wrote:
@sdesai
JH
On Apr 11, 2015, at 2:39 PM, Kim Trott [email protected] wrote:
Not sure Satyen's github handle but I'd be surprised used if webpack or browserify didn't allow you to compile code in/out based on build configuration. Not opposed to sweet if that's the way to do it, just question if our existing tools don't already have this support which would keep the stack simpler and improve build time.
On Apr 11, 2015, at 2:20 PM, jhusain [email protected] wrote:
No strong opinion on implementation here. If sweet is easy, I say we use it. @Ktrott https://github.com/Ktrott any objections?
— Reply to this email directly or view it on GitHub https://github.com/Netflix/falcor/issues/81#issuecomment-91927924.
— Reply to this email directly or view it on GitHub.
— Reply to this email directly or view it on GitHub https://github.com/Netflix/falcor/issues/81#issuecomment-91946415.
I couldn't see which compressor we're using in the build scripts, but uglify has pretty decent support for this. Lets you define symbol values on the command line, and strips out the resulting unreachable code.
https://github.com/mishoo/UglifyJS2 (Conditional Compilation)
This is great, but doesn't feel like something we need to do before Open Source milestone.
According to @trxcllnt and @michaelbpaulson: If we do #94 proposal a lot of the assertions / errors / confusion will go away.
Falcor meeting: Need to get more specific in this issue about where we want to assert in dev mode.
We have assertions in the public methods in Upgrayedd