I have done a huge rewrite on the build framework to enable lazy loading of node modules. Those changes are currently pushed into this branch: https://github.com/frontend-framework/build-framework/tree/lazy-load-plugins

The only thing I noticed is a faulty path rewrite of the gulp-clean-css plugin. The paths to our generated iconfonts in https://github.com/frontend-framework/frontend-framework/blob/demo-5.x/src/resources/scss/fonts/iconfont/_icons.scss#L1 are rewritten to something like "/dist/resources/css/resources/resources/fonts/icons/Icons.woff" in the build task. It seems that this isn't related to the usage of lazypipes. This seems to be more a result of the whole lazy module rewrite.

I already tried to use gulp-clean-css as before, with direct requires and not as a lazy plugin, with the same faulty result stated above. I think this plugin uses some kind of static storage for base paths and gets confused because we jump between /src, /.tmp and /dist during the build task.

I also removed the gulp-clean-css plugin and added gulp-cssnano. That produced slightly different minified css (seems that line-breaks in legal comments are not removed) but the generated paths are correct.

I don't want to simply change the plugins without any further discussions or getting you oppinions on this topic @timomayer @alxbenz

What do you think? Or maybe do you see the cause of this bug?

On an clean "frontend-framework" the "gulp build" task fails because no handlebars.templates.js file was created.

TODO: check if hbs is acitve in the projectConfig.js. For true always create a handlebars.templates.js even there is no .hbs in the hbs folder.
Also update frontend-framework and change the script.hbs and just add the hbs helper and templates if it's activated.

remove eot and ttf iconfont generation woff and woff2 is enough fo all browsers we support.

Current:
Images are not copied from the components folder.

Wish:
Images belonging to components stay with their components and get copied over to the build folder.

Gulp4 is final!
https://www.joezimjs.com/javascript/complete-guide-upgrading-gulp-4/

We need a really good documentation on how to develop the build framework locally. I already changed the way that gulp is used only locally inside the projects that helps already. But it is always tricky and not very stable (at least for me) to connect the build framework with the frontend part with yarn link. I haven't found a bullet-proof way to handle that.

Check Gemini. Looks like an interesting alternative for our visual regression tests
https://github.com/gemini-testing/gemini
to integrate with gulp: https://github.com/gemini-testing/gemini/blob/master/doc/programmatic-api.md
to use it with jenkins local builds: https://github.com/Saulis/gemini-browserstack
maybe use: https://github.com/gemini-testing/gemini-gui or https://github.com/gemini-testing/html-reporter for test results

during build read version number out of package.json and write a file called version in dist/resources/ folder.
For setups where our frontends are not stored version seperated it is important to see which version is currently deployed.

Why do we need a develop branch? Releases are managed via git tags and NPM versions. So there's not really a need for development branch isn't it?

Update readme.md remove references to jsx in v3 to v4 migration guide.
Add v4 to v5 migration guide including regex for template engine updates.

https://github.com/frontend-framework/build-framework/blob/7b32bf362849d7c003f904fb64604d4f7b02532b/tasks/handlebars.js#L33

In static rendereing the path name is always full pathname including {{include 'components/partial'}}
In dynamic hbs only basname is nedded {{> partial }}. Thus it appears that it is not possible to use dynamic and static rendering at the same time.

Probably this issue would be solved by adapting the path in the code linked to this issue.

The handlebars runtime partials have a different naming convention, than partials in the hb:static task.

The runtime partials should be updated to have the same name as the static partials to make them usable by both tasks interchangeable.

• static partials always use the full path name components/demo/partial
• dynamic partials use only the filename partial

If I include a component in layouts that does not exist, the following error message will appear:
partial not found: block helper fallback will be used and
context.fn is not a function in "C:\xxx\xxx\xxx\frontend-framework-master\src\pages\xxx.hbs"

Probably this part must be adjusted in hbs-helpers.js

// if partial doesn't exist use block failover if (!partial) { console.log(colors.red('partial not found: block helper fallback will be used')); return context.fn(this); }

Current:
js/css resources located in the components folder are built to the destination resources/components/
This leads to different paths for images/json assets and js/css assets in the dev environment.

Wish:
The js/css resources as well as the rest of resources, should be built to just components/ as they have a different meaning than resources.

Currently the error message for handlebars errors look like:
gulp-notify: [static:hb] Unexpected token h in JSON at position 7

The error message should also show the exact file where the error occured

Error: Cannot find module '/.../browserSupport.json' during npm run build

Fix: Show warning but don't break task execution

We should implement https://github.com/nodesecurity/gulp-nsp to check our node modules.

We need automated Travis CI tests for each gulp task.

I think about testing each task by its own, not only a full gulp build like it is done in Frontend Framework repository right now.

Testing approaches need to be discussed...

Currently the global debug flag "config.global.debug" creates huge amounts of console logs. This is no helpful information anymore.

I would like keep debugging information but on a more fine granular level. Maybe we should add flags like the "config.global.tasks" property for debug outputs.

Proposal would be:
config.global.debug: { cleanCss: false, useref: true, .... }

What do you think? @alxbenz @timomayer

In order to develop against an API it would be helpful to have environment variables to get API Keys or the the API url.

An example:

const apiKey = process.env.API_KEY
const apiUrl = process.env.API_URL

Start with gulp serve.

After view times webpack:ts runs it takes longer and longer and at some point running into:

Starting 'webpack:ts'...
<--- Last few GCs --->

[13936:0000020A1C0B82A0] 2906109 ms: Mark-sweep 1410.9 (1461.0) -> 1410.9 (1461.0) MB, 1618.4 / 0.0 ms last resort GC in old space requested

<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 000003CDEB725EE1
2: /* anonymous /(aka / anonymous */) [C:<projectPath>\node_modules\typescript\lib\typescript.js:20797] [bytecode=0000012474DB12A9 offset=3](this=000001CA07782311 ,ElementKind=
0000012985E5CA71 )
4: bindObjectLiteralExpression(aka bindObjectLiteralExpression) [C:\Users...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
1: node_module_register
2: v8::internal::FatalProcessOutOfMemory
3: v8::internal::FatalProcessOutOfMemory
4: v8::internal::Factory::NewTransitionArray
5: v8::internal::EhFrameIterator::DecodeSLeb128
6: v8::internal::JSReceiver::GetOwnPropertyDescriptor
7: v8::internal::JSReceiver::GetOwnPropertyDescriptor
8: v8::internal::JSReceiver::GetOwnPropertyDescriptor
9: v8::internal::JSReceiver::class_name
10: v8::internal::JSReceiver::GetOwnPropertyDescriptor
11: v8::internal::LookupIterator::PrepareTransitionToDataProperty
12: std::vector<v8::internal::compiler::MoveOperands * __ptr64,v8::internal::ZoneAllocator<v8::internal::compiler::MoveOperands * __ptr64> >::_Reallocate
13: std::vector<v8::internal::compiler::MoveOperands * __ptr64,v8::internal::ZoneAllocator<v8::internal::compiler::MoveOperands * __ptr64> >::_Reallocate
14: std::vector<v8::internal::compiler::MoveOperands * __ptr64,v8::internal::ZoneAllocator<v8::internal::compiler::MoveOperands * __ptr64> >::_Reallocate
15: std::vector<v8::internal::compiler::MoveOperands * __ptr64,v8::internal::ZoneAllocator<v8::internal::compiler::MoveOperands * __ptr64> >::_Reallocate
16: 0000014AEA2847A1

While running certain tasks (e.g. sass, hb:static) the livereload and htmlhint tasks trigger multiple times causing the site to reload several times.

From using the build-framework in an actual project we found that the naming of the hbs helpers collide with variable names. When sharing the name with a helper the variables don't get rendered.

This is problematic for example with the text helper and variables names text.

We should discuss how to handle this problem.

I propose two things:

• prefixing all handlebars helpers (for example "hText")
• prefixing variables with the component name that they belong to (for example text for an alert component should be named "alertText")

When using many partials the hb:static tasks gets slower. Currently running around 10 seconds in on of the projects.

This needs to be way faster.

We probably need to find a way to not always rebuild all partials and maybe only update the ones that are changed. Currently I have no idea how to fix this...

I often see that the second execution of the "clean:dist" task crashes. Happens on Mac, don't know if that is an issue on Windows too.

It is reproduceable by running "yarn build" twice. Second execution leads to the error (see below). A third execution runs fine again.

I think this is some kind of async rmdir execution that leads to that error. It seems to try a rmdir on a folder that was already removed.

[10:48:48] 'clean:dist' errored after 368 ms
[10:48:48] Error: EINVAL: invalid argument, rmdir '/Users/###/dist/resources/js/vendor/aem-core-wcm-components/extension/contentfragment/content/src/content/jcr_root/apps/core/wcm/extension/components/contentfragment/v1/contentfragment'
[10:48:48] 'build' errored after 372 ms
[10:48:48] Error in plugin 'run-sequence(clean:dist)'
Message:
    EINVAL: invalid argument, rmdir '/Users/###/dist/resources/js/vendor/aem-core-wcm-components/extension/contentfragment/content/src/content/jcr_root/apps/core/wcm/extension/components/contentfragment/v1/contentfragment'
Details:
    errno: -22
    code: EINVAL
    syscall: rmdir
    path: /Users/###/dist/resources/js/vendor/aem-core-wcm-components/extension/contentfragment/content/src/content/jcr_root/apps/core/wcm/extension/components/contentfragment/v1/contentfragment
Stack:
Error: EINVAL: invalid argument, rmdir '/Users/###/dist/resources/js/vendor/aem-core-wcm-components/extension/contentfragment/content/src/content/jcr_root/apps/core/wcm/extension/components/contentfragment/v1/contentfragment'
[10:48:48] 'build:dev' errored after 351 ms
[10:48:48] Error in plugin 'run-sequence(build)'
Message:
    EINVAL: invalid argument, rmdir '/Users/###/dist/resources/js/vendor/aem-core-wcm-components/extension/contentfragment/content/src/content/jcr_root/apps/core/wcm/extension/components/contentfragment/v1/contentfragment'
Details:
    errno: -22
    code: EINVAL
    syscall: rmdir
    path: /Users/###/dist/resources/js/vendor/aem-core-wcm-components/extension/contentfragment/content/src/content/jcr_root/apps/core/wcm/extension/components/contentfragment/v1/contentfragment
Stack:
Error: EINVAL: invalid argument, rmdir '/Users/###/dist/resources/js/vendor/aem-core-wcm-components/extension/contentfragment/content/src/content/jcr_root/apps/core/wcm/extension/components/contentfragment/v1/contentfragment'
[10:48:48] 'clean:dev' errored after 318 ms
[10:48:48] Error: EINVAL: invalid argument, rmdir '/Users/###/.tmp/resources/js/vendor/aem-core-wcm-components/extension/contentfragment/content/src/content/jcr_root/apps/core/wcm/extension/components/contentfragment/v1/contentfragment/clientlibs'
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] gulp: `node node_modules/.bin/gulp "build"`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] gulp script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/jan.rembold/.npm/_logs/2018-03-29T08_48_48_697Z-debug.log
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] build:gulp: `npm run gulp build`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] build:gulp script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/jan.rembold/.npm/_logs/2018-03-29T08_48_48_728Z-debug.log
error An unexpected error occurred: "Command failed.
Exit code: 1
Command: sh
Arguments: -c npm run build:gulp
Directory: /Users/###
Output:
".
info If you think this is a bug, please open a bug report with the information provided in "/Users/###/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

To better support integrating our components into cms systems or other projects we should provide markup for a component without handlebars template tags and includes.

todo:

• on gulp build add the markup of each component to the components folder
• html beautify: https://github.com/c0b41/gulp-htmltidy
• dev notes (backend integration comments) should stay in the markup! (this is maybe complicated since we are using hbs comments, but a must in my oppinion)

Use same handlebars helpers for static templating and dynamic templating.

Currently the "hb:static" task uses the helpers from /lib/hbs-helpers.js.
For dynamic templating on runtime we use a different file /resources/js/handlebars.helper.js.

It would be better to inject the handlebars.helper.js into the hb:static task, in order to have only one place to define helpers.

Disscussion so far:

@timomayer Not sure if this is a good idea we should not mixup build framework and frontend Framework
@alxbenz I think it would be good to at least have this opportunity: for example if one project uses some complex hbs template with custom helpers for runtime templating but also needs to have a static preview.
@janrembold In my opinion the best way would be to extract our helpers into its own repository and include it anywhere we need it

If you set uglify to false, js files located in the components/.../[js|ts] will not be copied to the dist folder.

Problem is, that the uglify task itself is copying the uglifiyed files to the dist folder.
To solve this, we need start an additional task, if the condition is false!

I'll already fixed it and will create a pr

Currently all *.ts files are used as webpack entry points. Especially in components these are way too much. This also affects performance of the (already unstable) webpack-stream task.

We have two places were TypeScripts can be found:

1. Resources (globally available)
2. Components (modular and component specific)

My proposal would be to limit entry points in component scripts from:

const webpackSourcePatterns = [
    path.join(config.global.cwd, config.global.src, config.global.resources, '**', '*.ts'),
    path.join(config.global.cwd, config.global.src, config.global.components, '**', '*.ts')
];

to

const webpackSourcePatterns = [
    path.join(config.global.cwd, config.global.src, config.global.resources, '**', '*.ts'),
    path.join(config.global.cwd, config.global.src, config.global.components, '**', 'index.ts')
];

With the newest version of the hbs parser(https://github.com/biotope/biotope-build/blob/master/lib/hbs-parser.js) the build process throws a warning if there is no custom handlebarsHelper file configured in the projectConfig.

It should only throw a warning if there is a handlebarsHelper file configured, but can not be found or is not valid. If there are no custom helpers and therefore is handlebarsHelper file is configured, there shouldn't be warning. The process should run through anyway.

The iconfont template src/resources/scss/fonts/iconfont/_icons.scss contains invalid SCSS syntax because it's a template for the generation of an scss file. This leads to annoying error highlights in e.g. Webstorm.

The file in biotope and also the config in biotope-build (https://github.com/biotope/biotope-build/blob/master/config.js#L120) should be renamed to _icons.tpl to fix this.

Also the config currently contains two icon sets, I don't know why. I think one should be sufficient. Further investigations would be appreciated!

eg: https://github.com/gersongoulart/gulp-swagger

1. evaluate if there is a better plugin for that
2. integrate it to build framework so we have only swagger json files in _mock folder and they auto generate /api/* endpoints

Currently we have a mixed JavaScript architecture between "legacy" ES5 and "modern" ES6 TypeScript Plugins. TS Plugins are bundled with Webpack that has some painful performance problems. Also we don't support plain ES6 JavaScript Plugins.

Problem is that I often see developers struggling with TypeScript when it is combined with external plugins that are not or faulty support typings. That makes the development process slow and painful. So I would really like to support ES6 Plugins as well.

First step is to remove webpack-stream plugin from gulp tasks and replace it with browserify/tsify... (#48) If this boosts performance and doesn't cause any memory leaks (like Webpack does currently) we can simply change the bundler silently.

Second step would be to support ES6 plugins that might be transformed to ES5 by e.g. Babelify. I propose to add a naming convention like "[pluginName].es6.js" to identify ES6 Plugins.

What do you think?

https://github.com/shakyShane/gulp-svg-sprites

Current:
If your project does not need a custom iconfont, you cannot remove the iconfont folders, as the build process will throw an error.

Wish:
The build process should be more tolerant and just ignore a non existing icon font folder.

Gulp takes a long time to startup, especially on Windows machines. It seems this is because of requiring lots of modules at the startup and also some bloated large modules like "gulp-util" (see gulpjs/gulp#282).

This is mostly an investigation task to see what is the problem behind that.

Proposal to get rid of gulp-util would be following replacements:

1. Warnings / Errors in pipes could use gulp-notify: https://github.com/mikaelbr/gulp-notify (see #notifyonerror section!)
2. Plain status logs, like "Task X is disabled", could be displayed with simple console.log() and the color module: https://github.com/marak/colors.js/

Hi guys,

We had a fix for this issue in old version of gulp build as you see here:
virtualidentityag/gulp-build-framework@90d1f77

Any particular reason that this was removed?

I'm thinking about testing all build framework tasks but would like to discuss different approaches of doing that in a useful and sustainable way.

Our framework (<5.x) had Travis tests for 2 different goals:

1. Complete build task executing successful
2. Compare created demo files (styles.all.min.css, scripts.all.min.js,...) with fixtures

Problems we discovered with test nr. 1 were very unspecific error messages (Build is broken).
Test nr. 2 was very fragile because any minor change within plugins or demo code structure changed the output and broke the tests.

I would like to discuss 2 different topics here:

1. What kind of tests should we write for the build framework?
2. What fixture data / demo content can we use?

While updating and removing old code we have been a little bit to optimistic reducing the useref task.
We need to re-add all bio and local helpers to the useref task again.

The current syntax for multiple resource folders is not very read friendly.
This should be optimized.

Example
return mergeStream(config.global.resources.map( function(currentResource) { return mergeStream(Object.keys(resources).map(function(key, index) { if( typeof resources[key] === 'string' ) { resources[key] = [resources[key]]; } return mergeStream(resources[key].map(function(file) { return gulp.src(config.global.node + '/' + key + '/' + file) .pipe(filter('*.js')) .pipe(gulp.dest(config.global.dev + currentResource + '/js/vendor/')); })); })); }));

Why? https://github.com/gulpjs/gulp/tree/master/docs/why-use-pump
In short: Gulp recommends to use pump to normalize error handling and close streams automatically.

I propose to rewrite all tasks to pump syntax and simultaneously add test automation to each task!
As an example the currently used uglify task is already implemented with pump.

As a POC I implemented a test area with Ava (https://github.com/avajs/ava), see /test in https://github.com/biotope/biotope-build/tree/task-testing that can easily be executed as TravisCI task

We need to update all packages to remove gulp-util warnings and other vulnerabilites. These are the outdated packages today:

Package               Current     Wanted      Latest Package Type           URL                                                   
autoprefixer          7.1.6       7.1.6       8.6.2  dependencies           https://github.com/postcss/autoprefixer#readme        
colors                1.2.5       1.2.5       1.3.0  dependencies           https://github.com/Marak/colors.js                    
fs-extra              5.0.0       5.0.0       6.0.1  dependencies           https://github.com/jprichardson/node-fs-extra         
globule               1.2.0       1.2.0       1.2.1  dependencies           https://github.com/cowboy/node-globule                
gulp-connect          5.0.0       5.0.0       5.5.0  dependencies           https://github.com/avevlad/gulp-connect#readme        
gulp-debug            3.2.0       3.2.0       4.0.0  dependencies           https://github.com/sindresorhus/gulp-debug#readme     
gulp-filter           3.0.1       3.0.1       5.1.0  dependencies           https://github.com/sindresorhus/gulp-filter#readme    
gulp-handlebars       4.0.0       4.0.0       5.0.2  dependencies           https://github.com/lazd/gulp-handlebars#readme        
gulp-hb               6.0.2       6.0.2       7.0.1  dependencies           https://github.com/shannonmoeller/gulp-hb             
gulp-htmlhint         1.0.0       1.0.0       2.1.1  dependencies           https://github.com/bezoerb/gulp-htmlhint              
gulp-jshint           2.0.4       2.0.4       2.1.0  dependencies           http://github.com/spalger/gulp-jshint                 
gulp-less             3.3.2       3.3.2       3.5.0  dependencies           https://github.com/plus3network/gulp-less#readme      
gulp-modernizr        1.0.0-alpha 1.0.0-alpha 2.0.4  dependencies           https://github.com/rejas/gulp-modernizr#readme        
gulp-notify           3.0.0       3.0.0       3.2.0  dependencies           https://github.com/mikaelbr/gulp-notify               
gulp-plumber          1.1.0       1.1.0       1.2.0  dependencies           https://github.com/floatdrop/gulp-plumber             
gulp-rename           1.2.3       1.2.3       1.3.0  dependencies           https://github.com/hparra/gulp-rename                 
gulp-replace          0.6.1       0.6.1       1.0.0  dependencies           https://github.com/lazd/gulp-replace#readme           
gulp-sass             3.1.0       3.1.0       4.0.1  dependencies           https://github.com/dlmanning/gulp-sass#readme         
gulp-sass-lint        1.3.4       1.3.4       1.4.0  dependencies           https://github.com/sasstools/gulp-sass-lint#readme    
gulp-size             2.1.0       2.1.0       3.0.0  dependencies           https://github.com/sindresorhus/gulp-size#readme      
gulp-svg2ttf          1.1.5       1.1.5       2.0.1  dependencies           https://github.com/nfroidure/gulp-svg2ttf             
gulp-svgicons2svgfont 3.0.1       3.0.1       5.0.1  dependencies           https://github.com/nfroidure/gulp-svgicons2svgfont    
gulp-watch            4.3.11      4.3.11      5.0.0  dependencies           https://github.com/floatdrop/gulp-watch#readme        
gulp-wrap             0.13.0      0.13.0      0.14.0 dependencies           https://github.com/adamayres/gulp-wrap#readme         
opn                   5.1.0       5.1.0       5.3.0  dependencies           https://github.com/sindresorhus/opn#readme            
prettier              1.12.1      1.12.1      1.13.5 dependencies           https://prettier.io                                   
pump                  2.0.0       2.0.0       3.0.0  dependencies           https://github.com/mafintosh/pump#readme              
require-dir           0.3.2       0.3.2       1.0.0  dependencies           https://github.com/aseemk/requireDir                  
sass-loader           6.0.7       6.0.7       7.0.3  dependencies           https://github.com/webpack-contrib/sass-loader        
style-loader          0.20.3      0.20.3      0.21.0 dependencies           https://github.com/webpack-contrib/style-loader#readme
typescript            2.8.3       2.8.3       2.9.2  dependencies           http://typescriptlang.org/                            
webpack               4.8.3       4.8.3       4.12.0 resolutionDependencies https://github.com/webpack/webpack                    
webpack               4.8.3       4.8.3       4.12.0 dependencies           https://github.com/webpack/webpack                    

Problem is: We never know which template/page is currently visible in the browser or better on which page is the developer working on.

In large projects it is still painful slow to statically re-render all templates (even though the new hb2 task has a 40-50% performance boost).

I would propose to add the possibility to overwrite the template glob pattern (https://github.com/biotope/biotope-build/blob/master/tasks/hb2.js#L13) inside local projectConfig.js.

If a developer has a large task and needs to see only a single page it would reduce the static rendering time to (n-1/n) where n = number of page templates. This means it would reduce the duration from seconds to milliseconds.

When trying to debug and setting uglify task to false the build task doesn't finish his job until the end.
So the dist folder is incomplete.

How to reproduce error :

Setting uglify task to false in projectConfig.js

Last tasks running :

[
        'uglify:resources:dist',
	'uglify:components:dist',
	'cleanCss:resources:dist',
	'cleanCss:components:dist'
],

Last command line in terminal
Finished 'cleanCss:resources:dist' after 2.6 s

Possible solution :

uglify is not returning a callback.

@alxbenz is aware of that issue.

Current behaviour
.spec.ts files in the ts folder are not ignored by the webpack build

Expected behaviour
.spec files should generally be ignored by the webpack ts build

Solution ideas
add **/*.spec.ts to the excludes

I found two issues in https://github.com/biotope/biotope-build/blob/master/lib/hbs-parser.js#L7

1. path.join is implemented with useless property ("/") and a already globally available cwd variable (config.globals.cwd)
2. There is no error handling around the handlebarsHelper require

This is fixed with PR: #64

When running gulp serve the cpu usage is very high. I think this is connected to the watch tasks.

With 5.0.0 we introduced polling on Windows machines to significantly decrease the tasks runtime, which is causing this issue: Without polling ~20%, with polling ~60%.
Without polling some tasks are taking longer and longer with each execution.

Possible solution is to use polling and reduce the interval time (see gulpjs/gulp#634 (comment))

We need a webpack handlebars loader to import hbs files for the usage inside Typescript plugins. Something like this would do the trick: https://github.com/pcardune/handlebars-loader

This loader imports or requires the handlebars template/partial and precomiles it. This precompiled file gets bundled into the TypeScript plugin and can easily be executed with a data JSON object. This returns the compiled HTML output of that partial as string.

In my first proof-of-concept I had problems using ES6 imports in TypeScript. Maybe this is the most difficult part of this implementation...

I noticed that we don't have a helper for ftf.img(), so I added one here:

a2475d2

When starting gulp serve with an intentional error inside a TS-file I see the same error in components and resources TS task. Though they are mapped to different source globs. The watch tasks seems to work fine afterwards.

[15:59:44] Version: webpack 3.8.1
Asset Size Chunks Chunk Names
jquery.plugin.advanced.js 10.9 kB 0 [emitted] jquery.plugin.advanced
Demo.js 6.28 kB 1 [emitted] Demo
jquery.plugin.simple.js 4.21 kB 2 [emitted] jquery.plugin.simple
BoilerplateOptions.js 2.74 kB 3 [emitted] BoilerplateOptions
jquery.plugin.advanced.js.map 12.7 kB 0 [emitted] jquery.plugin.advanced
Demo.js.map 6.48 kB 1 [emitted] Demo
jquery.plugin.simple.js.map 5.27 kB 2 [emitted] jquery.plugin.simple
BoilerplateOptions.js.map 2.47 kB 3 [emitted] BoilerplateOptions

ERROR in /Users/jan.rembold/Github/frontend-framework/app/components/typescript/ts/jquery.plugin.simple.ts
[tsl] ERROR in /Users/jan.rembold/Github/frontend-framework/app/components/typescript/ts/jquery.plugin.simple.ts(16,4)
TS1005: ';' expected.
[15:59:45] Version: webpack 3.8.1
Asset Size Chunks Chunk Names
jquery.plugin.advanced.js 11 kB 0 [emitted] jquery.plugin.advanced
Demo.js 6.28 kB 1 [emitted] Demo
jquery.plugin.simple.js 4.25 kB 2 [emitted] jquery.plugin.simple
BoilerplateOptions.js 2.74 kB 3 [emitted] BoilerplateOptions
jquery.plugin.advanced.js.map 12.8 kB 0 [emitted] jquery.plugin.advanced
Demo.js.map 6.5 kB 1 [emitted] Demo
jquery.plugin.simple.js.map 5.35 kB 2 [emitted] jquery.plugin.simple
BoilerplateOptions.js.map 2.47 kB 3 [emitted] BoilerplateOptions

ERROR in ./app/components/typescript/ts/jquery.plugin.simple.ts
[tsl] ERROR in /Users/jan.rembold/Github/frontend-framework/app/components/typescript/ts/jquery.plugin.simple.ts(16,4)
TS1005: ';' expected.