We are using the aurelia-cli for a single page application. It has the concept of multiple user modules (simple folders with view and view-models basically). Now as the application grows we want a way of not loading all modules up front. For example one user may only have access to 3 out of 20 modules.
Now the question is, how can we define bundles of modules and only load these on demand based on a condition at runtime?
We have managed to create bundles by editing the aurelia.json file. Our file looks like this for example
"bundles": [
{
"name": "my-module-bundle.js",
"source": [
"[**/my-module/*.js]",
"**/my-module/*.{css,html}"
]
},
{
"name": "app-bundle.js",
"source": [
"[**/*.js]",
"**/*.{css,html}"
]
},
...
This causes all the code for "my-module" to end up in its own bundle.
This also works in a sense that if no code has a reference to the "my-module" the bundle will not be downloaded and executed.
However... if we want to load this module dynamically based on a certain condition we are out of luck since we would need to reference the module thus causing it to download.
Is there any way around this problem? Can we for example load a bundle on demand using code?
Related
We have stumbled across a bug that I can only assume is a bug with the JSON API code. This is for the old laravel JSON API (in my composer.json file its "cloudcreativity/laravel-json-api": "^2.0")
The issue is when a resource is included multiple times (in different ways), it is possible to not get all the include information you asked for.
In my example, I am dealing with timesheets. Timesheets belong to a user. They are also approved by a user. Those users are usually different users, but not always. If I want to include both, I would add include=user,approved-by, and this works great.
The front end also sometimes needs to know the employeeType of the user, so we instead use include=user.employee-type,approved-by, and again this works, we get the employee type info for the user. The issue arises when the user is the same as the approver. It appears that JSON-API gets the approved-by user (without the employee type include data), then when it tries to get the timesheet user, it sees that is has already grabbed that user, and just stops there.
The difference in the output is:
The include with the related in
"employeeType": {
"data": {
"type": "employee-types",
"id": "1"
},
"links": {
"self": "link url",
"related": "link url"
}
},
Vs the include without all the related info
"employeeType": {
"links": {
"self": "link url",
"related": "link url"
}
},
We have a work around, where we need to include the employee type of the user and a the approver, but that seems cumbersome and annoying.
I was wondering if anyone knows if there is any good fix for this? Or if this has been fixed in the more recent version (could be the kick in the pants we need to actually migrate to the most recent version of the library)
I have a composer package A and B. A is for non-Laravel projects, while B slightly extends A with some Laravel specific files (configs, facades, etc).
How should B require A? Would it be "^1.1" or "1.*"? As the minor version should not break anything, the second one may be better, as I would not have to update the composer.json of B that often.
Then, should B match the version of the Laravel framework (currently "5.6.x")? Is that good or bad practice? Some packages do it that way, other create separate branches for the different framework versions.
How should B require A? Would it be "^1.1" or "1.*"? As the minor version should not break anything, the second one may be better, as I would not have to update the composer.json of B that often.
That's entirely a policy decision on your part. It sounds like you control both A and B, so it should be easy for you to make the judgement whether A really adheres to Semantic Versioning or not, and the relative risks to B for taking every random minor bump from A.
Then, should B match the version of the Laravel framework (currently "5.6.x")? Is that good or bad practice? Some packages do it that way, other create separate branches for the different framework versions.
Never! You're not responsible for versioning Laravel, you are responsible for versioning B. B's dependency on Laravel is defined in the package definition. You will likely have the occasion to bump at least the patch level on B independently of its dependencies. If you need to make it obvious which Laravel version that B is intended for, you can include that at the package name level (B-Laravel.X.Y.Z BX.BY.BZ), the build meta data (B.X.Y.Z+Laravel.X.Y.Z) or even at the publish/feed level (seperate web pages, REST URI's).
My recommendation is for you to start at 1.y.z and follow the current SemVer spec.
See
GitHub:semver/semver/265
GitHub:semver/semver/352
GitHub:semver/semver/265
If both packages are yours and Private then you can Iclude it in composer.json
Here is an example.
"repositories": [
{
"type": "package",
"package":
{
"name": "adnanmayo/laralogs",
"version": "0.1.4",
"source": {
"url": "https://repo.url",
"type": "git",
"reference": "master"
}
}
}
],
You have to also create a auth.json file for credentials access.
{
"http-basic": {
"bitbucket.org": {
"username": "username",
"password": "Passwrod"
}
}
Hope this helps.
After spending a few years locked into an ancient tech stack for a project, I'm finally getting a chance to explore more current frameworks and dip a toe into React and Webpack. So far, it's for the most part been a refreshing and enjoyable experience, but I've run across some difficulty with Webpack that I'm hoping the hive-mind can help resolve.
I've been poring over the Webpack 2.0 docs and have searched SO pretty exhaustively, and come up short (I've only turned up this question, which is close, but I'm not sure it applies). This lack of information out there makes me think that I'm looking at one of two scenarios:
What I'm trying to do is insane.
What I'm trying to do is elementary to the point that it should be a no-brainer.
...and yet, here I am.
The short version of what I'm looking for is a way to exclude certain JSX components from being included in the Webpack build/bundle, based on environment variables. At present, regardless of what the dependency tree should look like based on what's being imported from the entry js forward, Webpack appears to be wanting to bundle everything in the project folder.
I kind of assume this is default behavior, because it makes some sense -- an application may need components in states other than the initial state. In this case, though, our 'application' is completely stateless.
To give some background, here are some cursory requirements for the project:
Project contains a bucket of components which can be assembled into a page and given a theme based on a config file.
Each of these components contains its own modular CSS, written in SASS.
Each exported page is static, and the bundle actually gets removed from the export directory. (Yes, React is a bit of overkill if the project ends at simply rendering a series of single, static, pages. A future state of the project will include a UI on top of this for which React should be a pretty good fit, however -- so best to have these components written in JSX now.)
CSS is pulled from the bundle using extract-text-webpack-plugin - no styles are inlined directly on elements in the final export, and this is not a requirement that can change.
As part of the page theme information, SASS variables are set which are then used by the SASS for each of the JSX components.
Only SASS variables for the JSX components referenced in a given page's config file are compiled and passed through sass-loader for use when compiling the CSS.
Here's where things break down:
Let's say I have 5 JSX components, conveniently titled component_1, component_2, component_3, and so on. Each of these has a matching .scss file with which it is associated, included in the following manner:
import React from 'react';
import styles from './styles.scss';
module.exports = React.createClass({
propTypes: {
foo: React.PropTypes.string.isRequired,
},
render: function () {
return (
<section className={`myClass`}>
<Stuff {...props} />
</section>
);
},
});
Now let's say that we have two pages:
page_1 contains component_1 and component_2
page_2 contains component_3, component_4, and component_5
These pages both are built using a common layout component that decides which blocks to use in a manner like this:
return (
<html lang='en'>
<body>
{this.props.components.map((object, i) => {
const Block = component_templates[object.component_name];
return <Block key={i}{...PAGE_DATA.components[i]} />;
})}
</body>
</html>
);
The above iterates through an object containing my required JSX components (for a given page), which is for now created in the following manner:
load_components() {
let component_templates = {};
let get_component = function(component_name) {
return require(`../path/to/components/${component_name}/template.jsx`);
}
for (let i = 0; i < this.included_components.length; i++) {
let component = this.included_components[i];
component_templates[component] = get_component(component);
}
return component_templates;
}
So the general flow is:
Collect a list of included components from the page config.
Create an object that performs a require for each such component, and stores the result using the component name as a key.
Step through this object and include each of these JSX components into the layout.
So, if I just follow the dependency tree, this should all work fine. However, Webpack is attempting to include all of our components, regardless of what the layout is actually loading. Due to the fact that I'm only loading SASS variables for the components that are actually used on a page, this leads to Webpack throwing undefined variable errors when the sass-loader attempts to process the SASS files associated with the unused modules.
Something to note here: The static page renders just fine, and even works in Webpack's dev server... I just get a load of errors and Webpack throws a fit.
My initial thought is that the solution for this is to be found in the configuration for the loader I'm using for the JSX files, and maybe I just needed to tell the loader what not to load, if Webpack was trying to load everything. I'm using `babel-loader for that:
{ test: /\.jsx?$/,
loader: 'babel-loader',
exclude: [
'./path/to/components/component_1/',
],
query: { presets: ['es2015', 'react'] }
},
The exclude entry there is new, and does not appear to work.
So that's kind of a novella, but I wanted to err on the side of too much information, as opposed to being scant. Am I missing something simple, or trying to do something crazy? Both?
How can I get unused components to not be processed by Webpack?
TL;DR
Don't use an expression in require and use multiple entry points, one for each page.
Detailed answer
Webpack appears to be wanting to bundle everything in the project folder.
That is not the case, webpack only includes what you import, which is determined statically. In fact many people that are new to webpack are confused at first that webpack doesn't just include the entire project. But in your case you have hit kind of an edge case. The problem lies in the way you're using require, specifically this function:
let get_component = function(component_name) {
return require(`../path/to/components/${component_name}/template.jsx`);
}
You're trying to import a component based on the argument to the function. How is webpack supposed to know at compile time which components should be included? Well, webpack doesn't do any program flow analysis, and therefore the only possibility is to include all possible components that match the expression.
You're sort of lucky that webpack allows you to do that in the first place, because passing just a variable to require will fail. For example:
function requireExpression(component) {
return require(component);
}
requireExpression('./components/a/template.jsx');
Will give you this warning at compile time even though it is easy to see what component should be required (and later fails at run-time):
Critical dependency: the request of a dependency is an expression
But because webpack doesn't do program flow analysis it doesn't see that, and even if it did, you could potentially use that function anywhere even with user input and that's essentially a lost cause.
For more details see require with expression of the official docs.
Webpack is attempting to include all of our components, regardless of what the layout is actually loading.
Now that you know why webpack requires all the components, it's also important to understand why your idea is not going to work out, and frankly, overly complicated.
If I understood you correctly, you have a multi page application where each page should get a separate bundle, which only contains the necessary components. But what you're really doing is using only the needed components at run-time, so technically you have a bundle with all the pages in it but you're only using one of them, which would be perfectly fine for a single page application (SPA). And somehow you want webpack to know which one you're using, which it could only know by running it, so it definitely can't know that at compile time.
The root of the problem is that you're making a decision at run-time (in the execution of the program), instead this should be done at compile time. The solution is to use multiple entry points as shown in Entry Points - Multi Page Application. All you need to do is create each page individually and import what you actually need for it, no fancy dynamic imports. So you need to configure webpack that each entry point is a standalone bundle/page and it will generate them with their associated name (see also output.filename):
entry: {
pageOne: './src/pageOne.jsx',
pageTwo: './src/pageTwo.jsx',
// ...
},
output: {
filename: '[name].bundle.js'
}
It's that simple, and it even makes the build process easier, as it automatically generates pageOne.bundle.js, pageTwo.bundle.js and so on.
As a final remark: Try not to be too smart with dynamic imports (pretty much avoid using expressions in imports completely), but if you decide to make a single page application and you only want to load what's necessary for the current page you should read Code Splitting - Using import() and Code Splitting - Using require.ensure, and use something like react-router.
Actually, Strongloop allows developers to use default file for model-config.json. Inside it, there is a plenty of model definitions.
Why would I use an external model-config.json?
Because, I have a few projects sharing same models. Currently I am able to point models to an parent folder, this way:
'model-config.json'
{
"_meta": {
"sources": [
"loopback/common/models",
"loopback/server/models",
"../../shared-models-project/common/models", // this is external to the project
"../common/models",
"./models"
], ...
}
But after doing this change, I noticed that all models are also referenced in model-config.json file. Then the solution could be using an external model-config.json, located at shared-models-project/server/model-config.json instead of ./server/model-config.json.
But... is this possible? Any alternatives??
Loopback will also look for model-config.js (link), so you could create that file with something like:
module.exports = require('../../shared-models-project/server/model-config.json')
Is that what you meant?
Problem
This is how the app behaves:
every folder corresponds to a dynamic "feature" in the app.
features are independent of each other. (Inside each folder, none of the files have dependencies on other folders. However, each folder may use the same common libraries like jquery.)
not all features are needed all the time
within each folder, the files are not necessarily dependent on each other (but it makes sense to bundle them together because that's how a "feature" works)
the number of features is not fixed ... so a manual process where you have to manually update various configurations/files each time you add/remove a feature is NOT ideal
Desired Solution
Given what I described, what seems to make sense is to create chunks for each feature/folder and then load each chunk asynchronously (on demand) as needed by the app.
The problem is that this doesn't seem easy with webpack. I'd like to be able to do this
require.ensure([], function() {
var implementation = require('features/*/'+feature);
//...
where each feature (folder) goes in one chunk.
Unfortunately, if I'm understanding require.context correctly, that's not possible.
An alternative?
A possible alternative is the following:
use a single config file that lists each feature (we actually already use this),
use the config file to auto-generate a module that requires each folder asynchronously. (Basically, the "module" is a factory that the app can use to load each feature.)
add an entry point to the auto-generated module (force the chunks to be built).
So to summarize, add a build step that generates a factory that asynchronously load features. The problem is that this seems unnecessarily complex and I'm wondering if there's an better way to implement the solution. Or am I on the wrong track? is there a completely different solution?
Code
Folder structure
features
sl.graded.equation
graded.equations.js
graded.equation.edit.js
graded.equation.support.js
sl.griddable
griddable.js
griddable.edit.js
//...
Config file
{
"sl.graded.equation": [ //basically lists the feature "entry points" (not every file)
"sl.graded.equation",
"sl.graded.equation.edit"
],
"sl.griddable": [
"sl.griddable",
"sl.griddable.edit"
]
//...
}
Auto-generated factory
module.exports = function(feature, callback) {
switch(feature) {
//we can get fancy and return a promise/stream
case 'sl.graded.equation':
require.ensure([], function() {
var a = require('sl.graded.equation');
var b = require('sl.graded.equation.edit');
callback(a,b);
}
//...