Setup Monorepo #805

This is part of an arching plan to introduce Glimmer's rehydration/serializtion modes to Ember proper. There are 4 PR's that are all interwoven, of which, this is one. In order of need to land they are: Glimmer.js: glimmerjs/glimmer-vm#783 (comment) This resolves a rather intimate API problem. Glimmer-vm expects a very specific comment node to exist to know whether or not the rehydration element builder can do it's job properly. If it is not found on the first node from `rootElement` it throws. In fastboot however we are certain that there will already be existant elements in the way that will happen before rendered content. This PR just iterates through the nodes until it finds the expected comment node. And only throws if it never finds one. --- Ember.js: emberjs/ember.js#16227 This PR modifies the `visit` API to allow a private _renderMode to be set to either serialize or rehydrate. In SSR environments the assumption (as it is here in this fastboot PR) is that we'll set the visit API to serialize mode which ensures glimmer-vm's serialize element builder is used to build the API. The serialize element builder ensures that we have the necessary fidelty to rehydrate correctly and is mandatory input for rehydration. --- Fastboot: ember-fastboot/fastboot#185 This allows enviroment variable to set _renderMode to be used in Visit API. Fastboot must send content to browser made with the serialization element builder to ensure rehydration can be sucessful. --- EmberCLI Fastboot: ember-fastboot#580 Finally this does the fun part of disabling the current clear-double-render instance-initializer We first check to ensure we are in a non-fastboot environment. Then we ensure that we can find the expected comment node from glimmer-vm's serialize element builder. This ensures that this change will only effect peoeple who use ember-cli-fastboot with the serialized output from the currently experimental fastboot setup Then we ensure `ApplicationInstance#_bootSync` specifies the rehydrate _renderMode. This is done in `_bootSync` this way because visit is currently not used to boot ember applications. And we must instead set bootOptions this way instead. We also remove the markings for `fastboot-body-start` and `fastboot-body-end` to ensure clear-double render instance-initializer is never called.

…tion-serialization-from-glimmer Rehydration

Bump fastboot for rehydration release

Took me a bit to figure out if this was possible.

Allow html attributes

fastboot package upgrade to v1.2

When accessing a header, fastboot [will lowercase the string](https://github.com/ember-fastboot/fastboot/blob/master/src/fastboot-headers.js#L51-L57). However, when adding headers to the FastBootHeaders, the casing [is not changed](https://github.com/ember-fastboot/fastboot/blob/master/src/fastboot-headers.js#L20). This PR normalizes all headers as lower case strings, so `X-Headers` will be accessible on the `fastboot.request.headers` object.

Normalize headers to lower case

* issue ember-fastboot#193 * Added unit tests to check domContents.body includes boundary script tag

…te_body_in_domContents Moved the script tag fastboot-body-start boundary in _finalizeHTML method

funtion -> function

Fixed small typo

Closes ember-fastboot#196

* 💥 remove v4 * add v8 and v10

Remove .babelrc configuration file

…-sync Remove usage of deprecated exists-sync

Update Node.js support matrix

Required module path can be one of - `fs` (built-in Node.js module), - `abortcontroller-polyfill` (external main module), - `abortcontroller-polyfill/dist/cjs-ponyfill` (external submodule). FastBoot's build system requires only dependency whitelisting, thus looking only for the first part of module path.

Allow to require module path from whitelisted dependency

…/debug-4.1.0 fix(package): update debug to version 4.1.0

Update minimum version of simple-dom to 1.4.0.

v1.2.1 package upgrades

Currently only one test (fastboot-dependencies) is running on master. This PR fixes to run all tests. Will be adding revelant eslint plugins as next PR so this doesn't happen in future.

Fix to run all tests

Add Eslint to this project

Currently can't publish versions as I broke the preversion command. Sorry!

….json Fix package.json preversion command

Closes ember-fastboot#42

…fastboot-2.0.1 Greenkeeper/fastboot 2.0.1

Closes ember-fastboot#209

…/ember-source-3.8.0 Greenkeeper/ember source 3.8.0

Fix an incorrect `debug()` call

…/cookie-0.4.0 Update cookie to the latest version 🚀

…esponse Add README section on scraping issues and chunkedResponse

…stable

Bump fastboot

…-new-node-versions Dropping test support for node 4 and 6 and adding node 8, 10, 12 and stable

…tboot-middleware Bump fastboot-express-middleware

- For deployed app, dist/node_modules is required - For development mode in ember-cli-fastboot, require can fallback to lookup working directory node_modules

node API doc: https://nodejs.org/docs/latest-v6.x/api/modules.html#modules_file_modules Co-Authored-By: Robert Jackson <me@rwjblue.com>

…upport-matrix Update node support matrix

…ber-fastboot#225) Update node engines to match node versions we are testing against

Restore allowing fallback require from working directory

…st-path add Fastboot.distPath

There are no intentional semantic changes here, just cleanup of syntax while reviewing.

General repo cleanup.

This division was useful back when we had to support two different VM sandboxes (back in the Node 0.12 days 😱).

Make a single `Sandbox` base class.

Update dependencies/devDependencies to latest.

Now that we are only supporting Node 8+ we can always leverage async/await for our Node land code and we don't need RSVP directly as a dependency any more.

Remove `rsvp` dependency.

Document `reload` method.

This creates a `./dev` folder (for stashing helpful development scripts/utils/etc). The specific file added here (`dev/trace-multiple-visit.js') can be used for quickly tracing the characteristics of the following: * `require('fastboot')` - Labeled in the trace as `"require fastboot"` * `new FastBoot({ distPath: '...' })` - Labeled in the trace as `"initial setup"` * `await fastboot.visit('/')` - Labeled in the trace as `"first visit"` * `await fastboot.visit('/')` - Labeled in the trace as `"second visit"` * `await fastboot.visit('/')` - Labeled in the trace as `"third visit"` General usage and evaluation steps: 1. run the script (e.g. `node dev/trace-multiple-visit.js`) 2. Navigate Chrome to the `chrome:tracing` 3. Click "load" (in the top left) and navigate to this repo, select the `node_trace.1.log` file 4. Review / evaluate Co-authored-by: Kris Selden <kselden@linkedin.com>

Add dev script to make tracing easier.

This script is used for gathering basic memory statistics. It takes a heapsnapshot at the following locations: - `new FastBoot({ distPath: '...' })` - Saved in `snapshots/0-setup.heapsnapshot` - `await fastboot.visit('/')` - Saved in `snapshots/1-first-visit.heapsnapshot` - `await fastboot.visit('/')` - Saved in `snapshots/2-second-visit.heapsnapshot` - `await fastboot.visit('/')` - Saved in `snapshots/3-third-visit.heapsnapshot` General usage and evaluation steps: 1. run the script (e.g. `node dev/memory-usage.js`) 2. Navigate Chrome to the `about:blank` 3. Open the Chrome DevTools 4. Click into the "Memory" tab. 5. Click "Load" and load each of the files above (in order) 6. Review / evaluate

Add basic memory profiling script to `dev/` folder.

Co-authored-by: Kris Selden <kselden@linkedin.com>

Avoid reevaluating the app files and vendor files from scratch for each visit request. Co-authored-by: Kris Selden <kselden@linkedin.com>

…nce`) * Collapse `createEmberApp` into `buildApp` (since we are no longer separating the concepts of `Ember.Application` vs `Ember.ApplicationInstance`) * Stash the `Ember.Application` instance (along with the `Ember.ApplicationInstance` instance) after creation, for destruction later * Ensure destruction of both `Ember.Application` and `Ember.ApplicationInstance` occur when the `visit` has completed.

This helps ensure that if the dist files themselves are invalid, we fail fast (e.g. before the first `fastboot.visit()` invocation).

…t requests. This shows that mutating the prototype of an object used in multiple requests, leaks that mutation.

…ss visits

…fastboot#236) Refactor to use a single sandboxed context per visit request.

See RELEASE.md for details.

Add automated release setup.

We were using it primarily to test that our `FastBootHeaders.prototype.unknownProperty` method functioned properly. This refactors things to use a simulated `Ember.get` to allow the same test scenario to succeeed, but avoid having to depend on Ember itself. Note: this does not remove any "real" testing of various Ember versions, most of our tests are using fixtures with a fully compiled ember-cli applications.

…ber-dependency Remove ember-source from devDependencies.

This changes the system from providing default set of shared (and therefore mutable) global properties to using a builder function to generate the set of globals to be used _per visit_. The `buildSandboxGlobals` function will receive the default set of globals that FastBoot creates (currently this is `najax` and `FastBoot`), and whatever the `buildSandboxGlobals` function returns is what will ultimately be used. If `buildSandboxGlobals` is not provided, a default implementation is used (it is essentially `defaultGlobals => defaultGlobals;`). For example, to specify a custom global property named `AwesomeThing` to be accessed within the sandboxed context: ```js let fastboot = new FastBoot({ distPath: 'some/path/here', buildSandboxGlobals(globals) { return Object.assign({}, globals, { AwesomeThing: 'Taco Cat' }); } }); ``` If `sandboxGlobals` is passed (and `buildSandboxGlobals` is not) issue a deprecation and automatically create a `buildSandboxGlobals` of the following: ```js globals => Object.assign({}, globals, options.sandboxGlobals); ```

Refactor sandboxGlobals -> buildSandboxGlobals

* Recent versions of ember-data (3.12+) will automatically use `ember-fetch` (or global `fetch`) if present, and does not need special logic around `najax` * New applications (as of ember-cli@3.13.0) include `ember-fetch` by default, and do **not** include jQuery by default. Considering that `najax` is a `jQuery.ajax` emulation API, I think this library should avoid exposing it. * `najax` (as a dependency of this library) is difficult for the host application to control (e.g. get their own version), and would be better if they provided it themselves (via `buildSandboxGlobals` API) * Providing backwards compatibility is **very** easy (add `najax: require('najax')` via `buildSandboxGlobals`) * It seems better to "follow a spec" (suggesting `fetch` usage) For applications that still need `najax` (for example, if they are using an older ember-data version), they can do (example uses new `buildSandboxGlobals` API): ```js const najax = require('najax'); let fastboot = new FastBoot({ distPath: 'some/path/to/dist', buildSandboxGlobals(globals) { return Object.assign({}, globals, { najax, }); } }); ```

Remove najax from default set of sandbox globals.

An earlier refactor (to avoid floating the passed in `promise`) introduced invalid syntax (`Promise.all(firstThing, secondThing)`), this fixes the issue and adds tests ensuring we don't regress.

Fix invalid syntax with deferRendering.

This PR does a few things: Firstly, it allows the end consumer to decide if they want a sandbox per visit or to share a single sandbox over all visits. Second, it changes the default of `buildSandboxPerVisit` back to `false` therefore sharing a single sandbox for many `visit` invocations.

Remove Babel

Migrate to ESLint

Add Prettier

Expose option to allow a new sandbox per visit

Drop Node 8 support.

Update various dependencies to latest versions.

…endency Move request into dev dependencies

This is basic PR to build a new sandbox per visit after current request is complete. Specifically making sure the creation of sandbox is not tied to the request timeline itself but is done as an after effect. This is so that we do not build sandbox at the start of the request which is slow. Not specifically adding tests as this is just an internal implementation change. When we add queue management, I'll add more test cases of requests more than queue size or less than to cover those usecases.

…ox-after-request Build new sandbox after request is done

In order to increase the efficiency of the system when using `buildSandboxPerVisit` flag, we currently lazily create the sandbox for the next request. This is a single sandbox that is leveraged. In order to help with performance, we will be maintaining a queue of these sandboxes that can be leveraged by the requests. When the sandbox is empty, it will eagerly create the sandbox instead of caching the pending request and letting it run when the sandbox is available. This is primarily so that we don't end up starving the system when number of requests is far greater than queue size and the system cannot recover from storing the sandbox for next requests. Finishing the request (even if in degraded fashion) brings in better resilience. In addition, when requests cannot use the sandbox from the queue, we now emit analytics information about the request in the result object. This helps applications using this flag to track if their QPS is greater than Queue size and bump the queue size. The queue size is provided when the app is created and pre-emptively the queue is filled up so initial requests don't starve. Updated README as well with this new public API.

…anagement Add sandbox queue management when using buildSandboxPerVisit

…/release-it-lerna-changelog-2.0.0 Update release-it-lerna-changelog to the latest version 🚀

Append extra classes to existing ones in the body and html tags

This implements a new v5 schema for fastboot. Unlike the previous json-oriented formats, this is an html-oriented format. HTML is better understood by general purpose build tools, which makes it easier to integrate with embroider. It also allows us to eliminate some redundancies -- for example, the app config no longer needs to exist in both package.json and the meta tags, since the HTML oriented format can use it directly from the meta tags. In package.json, the v5 schema supports: - `fastboot.schemaVersion: 5` - `fastboot.moduleWhitelist: []`: unchanged meaning from v4. - `fastboot.htmlEntrypoint: 'index.html'`: the path to your HTML entrypoint file - `name`: note that in the new format, we take the appName directly from the package.json top level. This field is used for nothing else by the time we get to fastboot, so there was no reason for redundancy. The HTML entrypoint file is any valid HTML, plus these fastboot-specific extensions: - `<fastboot-script>` tags work like `<script>` tags, but they will only run in fastboot and be stripped out before serving to browsers. - `<script data-fastboot-ignore></script>` will *not* run in fastboot, and the data attribute will be stripped out before serving to browsers. - `<script src="https://some-cdn.com/app.js" data-fastboot-src="assets/app.js"></script>` tells fastboot the local path to an asset that may have a different public URL for browser consumption. The data-fastboot-src attribute is stripped before serving to browsers. New html-oriented manifest format for embroider implementing data-fastboot-ignore and data-fastboot-src making htmlEntrypoint the new v5 schema And refactoring so we truly hide the differences in schema versions from the rest of the program. schema v5 This makes the htmlEntrypoint format be the official v5 schema.

Migrate to ESLint

See ember-cli/ember-cli#2903

Use append to support multi-value headers

`npx create-rwjblue-release-it-setup`

Add release automation setup.

…finalization

…github-actions

…ase-setup

I find this behavior to be _very odd_, but it matches what we have under test. Specifically, it seems bizarre to call `next` and then do _anything_ with the response still, calling `next` signifies "I'm done here"!!?!?!!

Update to fastboot@3.1.0

Remove legacy Node.js support leftovers

Drop Node 8 and 13 support

…oot-gcloud-storage-downloader

…oot-gcloud-storage-notifier Add link to fastboot-gcloud-storage-notifier in README

Add link to s3-notifier

…flict

…ed-release-setup Add release automation.

Migrate to GitHub Actions.

Includes a major bump of `chalk`, but the breaking changes (after reviewing) should not affect us.

…ndencies

* Update eslint to 7.x * Move from `lint:js` to `lint` * Use `npm-run-all` instead of `&&` in scripts * Move `NODE_ENV` configuration into `.mocharc.js` (makes it so that `mocha test/some-file-test.js` works on its own)

…shots

It's covered in package.json engines. Also removes https://embadge.io badge which seems unavailable.

Remove node version in Readme

…tadata

# Conflicts: # packages/fastboot-express-middleware/package.json run tests in ci skip legacy mocha tests skip fastboot ci on windows fastboot ci test is not working correctly on windows

port fastboot test into integration-tests package

add integration-test in ci rename lib to test-helper

Commits on Jun 6, 2018

fastboot package upgrade to v1.2

izelnakri committed Jun 6, 2018

Configuration menu

View commit details

Copy full SHA for 6e546c7

Browse repository at this point

Copy the full SHA

6e546c7 View commit details

Browse the repository at this point in the history

Commits on Sep 17, 2018

release v1.2.1 🎉

stefanpenner committed Sep 17, 2018

Configuration menu

View commit details

Copy full SHA for 8562d2d

Browse repository at this point

Copy the full SHA

8562d2d View commit details

Browse the repository at this point in the history

Commits on Apr 28, 2019

Fix an incorrect debug() call

CvX committed Apr 28, 2019

Configuration menu

View commit details

Copy full SHA for aa752f7

Browse repository at this point

Copy the full SHA

aa752f7 View commit details

Browse the repository at this point in the history

Commits on Jul 16, 2019

Update node support matrix

sdhull committed Jul 16, 2019

Configuration menu

View commit details

Copy full SHA for a4f7451

Browse repository at this point

Copy the full SHA

a4f7451 View commit details

Browse the repository at this point in the history

Commits on Jan 4, 2020

Remove Babel

bobisjan committed Jan 4, 2020

Configuration menu

View commit details

Copy full SHA for 367347f

Browse repository at this point

Copy the full SHA

367347f View commit details

Browse the repository at this point in the history

Commits on Jan 18, 2020

Add Prettier

bobisjan committed Jan 18, 2020

Configuration menu

View commit details

Copy full SHA for 3aec19f

Browse repository at this point

Copy the full SHA

3aec19f View commit details

Browse the repository at this point in the history

Commits on May 21, 2020

handle customized rootURL

Edward Faulkne committed May 21, 2020

Configuration menu

View commit details

Copy full SHA for 3fae95c

Browse repository at this point

Copy the full SHA

3fae95c View commit details

Browse the repository at this point in the history

Commits on Oct 25, 2020

Update FastBoot v3

bobisjan committed Oct 25, 2020

Configuration menu

View commit details

Copy full SHA for 82362c9

Browse repository at this point

Copy the full SHA

82362c9 View commit details

Browse the repository at this point in the history

Setup Monorepo #805

Setup Monorepo #805

Commits on Feb 23, 2018

Commits on Mar 8, 2018

Commits on Mar 11, 2018

Commits on Mar 13, 2018

Commits on Mar 29, 2018

Commits on May 27, 2018

Commits on Jun 6, 2018

Commits on Jun 7, 2018

Commits on Jun 16, 2018

Commits on Jul 11, 2018

Commits on Sep 11, 2018

Commits on Sep 17, 2018

Commits on Sep 27, 2018

Commits on Oct 8, 2018

Commits on Nov 21, 2018

Commits on Nov 22, 2018

Commits on Nov 29, 2018

Commits on Dec 10, 2018

Commits on Dec 17, 2018

Commits on Dec 19, 2018

Commits on Dec 20, 2018

Commits on Jan 21, 2019

Commits on Feb 18, 2019

Commits on Feb 19, 2019

Commits on Apr 28, 2019

Commits on Apr 29, 2019

Commits on May 6, 2019

Commits on May 16, 2019

Commits on May 17, 2019

Commits on Jun 6, 2019

Commits on Jul 12, 2019

Commits on Jul 15, 2019

Commits on Jul 16, 2019

Commits on Jul 23, 2019

Commits on Jul 24, 2019

Commits on Jul 25, 2019

Commits on Jul 26, 2019

Commits on Aug 5, 2019

Commits on Sep 11, 2019

Commits on Oct 24, 2019

Commits on Oct 25, 2019

Commits on Oct 27, 2019

Commits on Oct 29, 2019

Commits on Oct 30, 2019

Commits on Oct 31, 2019

Commits on Nov 1, 2019

Commits on Nov 4, 2019

Commits on Nov 8, 2019

Commits on Jan 4, 2020

Commits on Jan 15, 2020

Commits on Jan 18, 2020

Commits on Jan 19, 2020

Commits on Jan 31, 2020

Commits on Feb 5, 2020

Commits on Mar 3, 2020

Commits on Mar 10, 2020

Commits on Mar 13, 2020

Commits on Mar 18, 2020

Commits on Mar 23, 2020

Commits on Mar 24, 2020

Commits on Mar 25, 2020

Commits on Mar 26, 2020

Commits on Apr 7, 2020

Commits on Apr 12, 2020

Commits on May 6, 2020

Commits on May 19, 2020

Commits on May 21, 2020

Commits on May 26, 2020

Commits on Jul 21, 2020

Commits on Aug 16, 2020

Commits on Oct 7, 2020

Commits on Oct 16, 2020

Commits on Oct 23, 2020

Commits on Oct 24, 2020

Commits on Oct 25, 2020

Commits on Oct 26, 2020

Commits on Oct 29, 2020

Commits on Oct 30, 2020