Skip to content
This repository has been archived by the owner on Jan 11, 2023. It is now read-only.

Serialize preloaded data for initial page and serve to client #87

Merged
merged 11 commits into from
Jan 14, 2018

Conversation

Rich-Harris
Copy link
Member

This PR looks bigger than it otherwise would, because it includes a bunch of semi-related test stuff, and adds a helper for printing nice startup errors (which could be made more general if necessary) to help move people away from %sapper.main%

@Rich-Harris
Copy link
Member Author

Glory be! The tests finally pass on Travis, now that it's not calling preload on the client and blowing away the server-rendered HTML before it's evaluated.

@Rich-Harris Rich-Harris merged commit 14df138 into master Jan 14, 2018
@Rich-Harris Rich-Harris deleted the gh-3 branch January 14, 2018 16:50
.then(id => {
assert.equal(id, 42);
});
});
});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome stuff!

Is this test supposed to be removed?

You know this better than me, but is it a good idea to have both package-lock.json and yarn.lock in the same repository?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ack! well spotted, thanks — must have got lost when I was trying to merge some stuff. have added it back.

Bloody lockfiles. Removing yarn.lock

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you explain the reason for removing lock files? I always commit mine. (Yarn being the preferred tool in my builds.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lock files are used to get consistent installs across machines. Having 2 separate lock files in the same repository violates this out of the gate. Having either yarn.lock or package-lock.json in the repository is a good idea, though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you mean to say Sapper only supports NPM? That would make more sense. But there's nothing wrong with committing Yarn and NPM lock files—it is just more effort.

Since Yarn has been pretty reliable almost since inception, I barely noticed the release of NPM 5, and just now had to go read up on the difference, including the lock files.

If this ticket is ever closed yarnpkg/yarn#3614 then it may be that Yarn folks won't need to fret about frameworks, etc., that rely solely on NPM, but until then, we should state it more explicitly in the docs that Sapper relies on NPM; use Yarn at your own expense (YMMV).

ALTERNATIVELY, you can commit both lock files and explicitly support both, but give the Sapper team a little more work to do. I could easily see y'all doing the first, with a well-worded explanation somewhere.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants