Use parse/stringify from flatted lib to support circular structures (fixes #222)#240
Conversation
| import { DebugMove } from './debug-move'; | ||
| import { GameLog } from '../log/log'; | ||
| import { restore } from '../../core/action-creators'; | ||
| import { parse, stringify } from 'flatted/cjs'; |
There was a problem hiding this comment.
I think it should be flatted/esm
From https://github.com/WebReflection/flatted#flatted
// ESM
import {parse, stringify} from 'flatted/esm';
// CJS
const {parse, stringify} = require('flatted/cjs');There was a problem hiding this comment.
I aggree. I changed to esm locally, and changed the rollup config accordingly. However, now tests do not run anymore because they fail to resolve the "export" keyword inside flatted/esm/index.js.
Somehow jest now needs to be told to transform ES6 modules also. Likely another change in .babelrc is necessary.
There was a problem hiding this comment.
So how was I able to push this branch at all - it should have been caught by the prepush hook? Since I can't push the esm variant because now tests are failing :(
As far as I understand this, it should work since .babelrc contains transform-es2015-modules-commonjs inside test env directly.
There was a problem hiding this comment.
You can push even if tests are failing using: git push --no-verify
There was a problem hiding this comment.
Except I didn't.
There was a problem hiding this comment.
Sometimes tests can pass locally but fail on Travis if it depends on something in node_modules that's set up correctly locally but incorrectly in package.json.
There was a problem hiding this comment.
Oh I thought your question was about how to push now that the tests are failing.
|
Well and now one cannot run the dev server anymore because it complains that "export" keyword is unexpected inside flatted/esm. |
|
Will take a look. |
|
As a sidenote, why is there a separate coverage check when the Travis build also checks coverage? |
|
Fixed by just importing: Their package.json includes a About the coverage check, are you talking about why we use Coveralls in addition to Travis? Travis merely runs the build and reports the coverage to Coveralls, which has better tooling like the ability to view covered / uncovered lines. In theory it is possible to have Travis just spit out a coverage number and fail the build if it doesn't meet a threshold, but Coveralls is useful enough that I decided to keep them separate. |
This PR fixes the problem described in #222. It replaces the use of JSON.stringify/JSON.parse with functions from the flatted library.
Instead of just fixing that problem, this PR changes stringify/parse to flatted in all parts that consitute the library itself - i.e. the examples and the storybook are unchanged.
Checklist
master).