Tests that build currently use the repository's directory as the outDir. They build, they clean, and it happens within the repo.

Should happen in a temp directory, so to not conflict with local repo work.

We need to write a proper serializer and deserializer for the manifest parsing rather then using the toJSON proprerty

Currently the test for 'reloaded-iframe' example is flaky on windows.
If adding "sleep(100)" before the button click on the test, it passes.
Need to understand what to "waitFor" in the test

Will be very useful to have JSDocs to the Registry function.

copied from another project (#125)

After a discussion made with @nadavwix and @barak007 we need the environments variables infrastructure as a part of the feature declaration.
A new Entity will be defined: EnvironmentVariable.
It will have a mandatory property of the default value, and optionally a serializer function, for cases we need to serialize the string value to a different one. it will have the following interface:

interface IEnvironmentVariable<T> {
  default: T;
  serializer?: (stringValue: string) => T;
}

And the usage will be as follows:

export default new Feature({
    id: 'myFeature',
    api: {
        myVariable: new EnvironmentVariable({ default: 'value' }).defineEntity(processingEnv),
        mySecondVariable: new EnvironmentVariable({ default: 5, serializer: (raw: string) => parseInt(stringArg) }).defineEntity(mainEnv) 
    },
    dependencies: [],
})

These arguments could be used in the feature.environment setup file as follows:

MyFeature.setup(mainEnv, ({ mySecondVariable }) => {
    document.body.innerText = JSON.stringify(mySecondVariable.getValue())
}

The appropriate cli call will look as follows:
yarn start -f my-feature --myFeature.mySecondVariable 8

@nadavwix @AviVahl @barak007 please share your thought on this

the entire code of generating a web entrypoint (create-entrypoint.ts in engine-scripts) is a combination of template strings.

This makes this peace of code to be very prone to errors and bugs, and makes this code non testable.

We should refactor this file to be as typed as possible and the code of the entrypoint itself to be very lean

got broken, but wasn't caught due to false-positive tests.
see info at #510

There are some request that going through the communication service, that should not timeout in 5 seconds (importing git assets and dependencies for an example).

Expected Behavior
No timeout error when making long async calls to different environments

Current Behavior
after 5 seconds the request handler dies and when the response returns, it has no handler to handle it.

Proposed fix
const someAsyncFunction = async () => {...}
COM.setCustomTimeout(someAsyncFunction, 20000) // for someAsyncFunction handler, the timeout will be 20 seconds instead of 5 every time it will be called.

Here's a stripped down example: here.

Not sure exactly what is happening here, but something seems to be getting lost in translation.

Currently, cross-environment service subscriptions can only be defined as myService.subscribe(listener)

It would be really useful to also allow event name as the first argument: myService.subscribe(event, listener)

Right now the engine doesn't warn you or throw an error when you try to do this, the subscription just silently fails to work.

As far as I can tell, supplying config to withFeature only overrides node config and not all config...

We currently get "server disconnected" popup firing DURING work in slow environments, and also when coming back from sleep (on my mac at least).

We should attempt to re-connect on certain interval to prevent users from needing to refresh the WCS page

@tomermes

When starting the engine it picks up every .config.js file as a feature config file. E.g. when running a feature called project-picker I'm getting the following:

$ engineer start -f project-picker -c project-picker/example --singleFeature
Available Configurations:
http://localhost:3000/main.html?feature=project-picker&config=project-picker/engine
http://localhost:3000/main.html?feature=project-picker&config=project-picker/wcs
http://localhost:3000/main.html?feature=project-picker&config=project-picker/webpack

Because in my project I have engine.config.js, wcs.config.js, and webpack.config.js, which are obviously not feature configs.

Multiple people who used this project (me included) raised an issue that the project is broken, because no matter which config they choose it fails to work.

Possible solutions:

1. Use a more specific extension for feature configs, e.g. .feature.config.ts
2. Validate discovered configs and don't show invalid ones.
3. Allow to specify a glob pattern for config discovery.

We currently have a single use of this flag.

After we remove this blockage - please remove the option to allow errors at all

moved from another project (#143)

Currently we do not define the way in which feature packages (npm packages) expose their inner parts, and how those exports would be consumed by a user.

tomrav:
New file suggestion: index.[feature-name].[targetRuntime].ts
These index files are used to export additional content from the feature package. e.g. components, typings, drivers, reusable configurations and more
Each target runtime will result in a separate bundle, assuring that environment specific code will not be included where it is not needed, and should not run
These files can be found in both the src and test-kit directories of a package
Allowed target runtime values are: browser, node, worker and universal
It remains an open question how exactly an import from these files would look like and what project structure actually gets published to NPM.

tomrav:
AviVahl any thoughts about how up to date this issue is? I believe we've solved the publishing issue for now, not sure if the particulars are documented anywhere.

AvIVahl
Issue is still relevant. typescript gets into main/preview bundles quite often because of that.

When running inside electron, we want to start environments that talk to other environments via the built-in IPC.

Pretty much the title, but this error (and it's call stack) don't give much to go on when debugging.

Would be more helpful (if possible) to have some indication of what's going wrong.

Moved from other repo: issues/94

Currently the socket timeout is 5 seconds. meaning that the socket gets disconnected if no response from the server was received within 5 seconds.

We should increase it, maybe to 10-15 seconds?

We want to be able to customize the favicon. Whether we have a path or an actual icon, we are unable to tell the engine to use it.

Regarding Electron, I am not sure how it works but the idea is the same, we want to be able to customize the app's icon.

Expected Behavior

Bundle once?
Notify once?

Current Behavior

Steps to Reproduce (for bugs)

1. Run some app that uses engine
2. Notice multiple messages on terminal

prepack script should be tested

We want a fresh copy of config evaluation result every time a config is requested.
We need to invalidation to be deep, as we have config files importing other files.

there's flakiness on master atm.
looks like:

1) Application
@wixc3/engine-scripts:        "after each" hook for "allows specfiying a config":
@wixc3/engine-scripts:      Error: Timeout of 30000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (/home/travis/build/wixplosives/engine/packages/scripts/test/application.unit.ts)

It happens when closing Application. we've noticed socket.io sometimes doesn't resolve.

Further investigation required.

when there are bundling errors or warnings, test should fail

As a next step to engine run and build, we want to create a node file that will act like the 'createEntrypoint' file in the browser

Given a feature some-feature, which imports typescript in one of it's environments via a simple import ts from 'typescript', we want engine users:

• to be able to say this dependency shouldn't be bundled (external).
• to have a way to load it and set it up dynamically before the environment parts that require typescript are evaluated.

Hey,
I would like to easily see the dependencies between features in a node graph format like this:

Ideally by defining my feature entry point.

Extra points:

Additional data like feature environments, feature API, Config, links and more!!!!

We should consider adding browser to getLoadedFeature return value for usage in ix tests (i.e browser.pages()).

For example, with yarn start:all --projectPath ../some-project --freshlyCloned, the value of freshlyCloned will be undefined, not true. However, with yarn start:all --freshlyCloned --projectPath ../some-project, the value of freshlyCloned will be properly set to true.

currently engine-scripts includes both dev-time and runtime functionality, such that its consumers are dependant on html-webpack-plugin.

consider separating the runtime functionality to a separate location,
s.t only the runtime functionality will be consumed by component studio and it wouldn't require html-webpack-plugin as a prerequisite

When trying to run a feature that is designed to work on a specific env context (live-server/worker) on another env context, it would be helpful the get a meaningful error\alert.

if you try to start the engine with no web environments it is hanging waiting for the webpack compiler

Sometimes a feature needs to define a service for its internal use. But currently there's no way to prevent other features from using it.

Currently at #16 we added RUN_OPTIONS to the engine lifecycle functions, but we don't pass anything to the node environment.
We should parse the cli parameters and add them to the runEngineApp which happens for node environments

Moved from scalable:
https://github.com/wixplosives/scalable/issues/283

We need to add the 'engine test' script which will replace the yarn test scripts.

The command should support the following arguments:

path - path of the folder of test file or folder (default value - cwd)
flavor - whether its an ix or spec test
env - whether run tests on node or browser
debug - whether should pause on breakpoints
watch - whether run test once or multiple times
Also need to update readme.md file in engine-scripts to include all possible engine commands and all possible arguments for each command

If I use a multi event emitter with allowRemoteAccess and I pass more than one argument to the subscribe method I get this error:
Failed to execute 'postMessage' on 'Worker': function () { [native code] } could not be cloned.
(specifically, the first argument is string & the second is a function).
It seems that callMethod calls addOrRemoveListener only if there is only one argument and it's a function.

When running engine start on a package with features, but without config:

• build finishes successfully.
• browser features still run when going to /main.html?feature=<featureName>.
• links aren't printed.
• features don't show up in the dashboard.

currently the node_modules of a feature are not served.

We should be able to serve them so they will be accessible on runtime

• readme in the repo root (what this is, what it solves, what is found where, some high level design, how to use)
• readme in each example (what this example shows, how to use it)
• example for testing an application written in the engine

When running engineer --help, descriptions of commands are missing. E.g. what the difference between engineer start and engineer run?

ꕤ ~/Projects/component-studio yarn engineer --help
yarn run v1.22.10
$ /Users/alexeyl/Projects/component-studio/node_modules/.bin/engineer --help
Usage: engineer [options] [command]

Options:
  -V, --version                   output the version number
  -h, --help                      display help for command

Commands:
  start [options] [path]
  build [options] [path]
  create [options] [featureName]
  run [options] [path]
  clean [path]
  help [command]                  display help for command

Looking at a single command, let's say engineer create, option descriptions are either unclear or missing:

ꕤ ~/Projects/component-studio yarn engineer create --help
yarn run v1.22.10
$ /Users/alexeyl/Projects/component-studio/node_modules/.bin/engineer create --help
Usage: engineer create [options] [featureName]

Options:
  --path <path>
  --featuresDir <featuresDir>    path to the features directory in the project (optional)
  --templatesDir <templatesDir>  path to a customized templates folder (optional)
  -h, --help                     display help for command

• What's the difference between path and featuresDir?
• What's used as the default featuresDir and templatesDir?
• How the feature should be named: camel case, kebab case?
• What does the command do if templatesDir is not provided?
• What template should look like?

engineer start

• What should be passed as the --feature flag? Is it a file path, feature ID?
• What is --config, --inspect, --port, --publicPath, --open, --publicConfigsRoute?
• In the description of --singleFeature what does it mean to "build only the feature set by --feature"?

Related: Topics for Engine Documentation

The generated manifest.json points the wrong location after build.
It seems to point to '../../' instead of the correct path.

Currently, when calling a service defined in a single-endpoint browser environment from a node environment, the engine either completes the request, or leaves it in a pending state indefinitely (if there are no browser environments running at the time of the request).

Instead, the engine should throw an error to prevent incorrect usage. Maybe we could even guarantee this at compile time instead of throwing a runtime error?

to reproduce: use prepack

getRunningFeature isn't using the engine.config.js featureDiscoveryRoot which is set globally

(issue moved from another project)

change the button text to tell me it is working