In another project, I am dealing with yet more build system churn. My project used to build, I turned on eslint, made suggested fixes, and it stopped running a full python build (yarn run build still works). I had a thought. This is a general point, not about anything specific we're doing with IPYReact yet.
For production you of course want all strictness and errors turned up. For dev, especially exploratory dev its useful to slowly turn these features on... to just get something working first.
It's helpful to have simpler examples that require less build carefullness so ideas can be tried out. If I'm developing, I just want to be able to import your code without having the exact same build config.
BTW the problem I just fixed was remedied by replacing
import * as data from '../package.json';
with
const data = require('../package.json');
the import syntax made eslint happy, but conflicted with something in the jupyter buildchain.
In another project, I am dealing with yet more build system churn. My project used to build, I turned on eslint, made suggested fixes, and it stopped running a full python build (
yarn run build
still works). I had a thought. This is a general point, not about anything specific we're doing with IPYReact yet.For production you of course want all strictness and errors turned up. For dev, especially exploratory dev its useful to slowly turn these features on... to just get something working first.
It's helpful to have simpler examples that require less build carefullness so ideas can be tried out. If I'm developing, I just want to be able to import your code without having the exact same build config.
BTW the problem I just fixed was remedied by replacing
with
the
import
syntax made eslint happy, but conflicted with something in the jupyter buildchain.