Send X-Clacks-Overhead header as part of request

To keep the header alive, we should send it when initiating a request.  Conformant endpoints should include the header in the response without logging and intermediaries should forward the header without logging.

I think this is a great idea on principle but am concerned about the possible impact on performance caused by a blocking intercept of every single http request made by the browser. You might have more experience than me, do you know if this is a valid concern or do you think it would be negligible? The Chrome dev tools seem to have a nice performance auditing system, it might be worth having a play with that.
Maybe it could be offered to users as an configurable option.

Unfortunately this is the first time I've done anything with a Chrome extension, so I can't say if it would cause an issue, but I share your concern.  It would cause less overhead if we just added the header without doing the check.  What do you think about that?  Since the header should not exist prior to this code running.

Hmm. I've finally come back to this after giving it a bit of a break. I thought it would be nice to make your suggestion an optional feature. It is pretty easy to add an options page. Saving people's choice of option requires access to the Chrome local storage, however, which would require new permissions... last time I required new permissions to implement a popularly requested feature (at exactly the same 'level' as before) it caused a bit of a mess and instantly halved the number of users.
I don't think it's really worth the trouble, users are a fickle bunch. If you really want this feature I would suggest forking the repository, sorry.


MSID: 86899 Version: 1 DOI: 2<IP_ADDRESS>5977

"msas": "Evolutionary Biology"
"msid": "86899"
"preprintDoi": "10.1101/2<IP_ADDRESS>5977"
"Reviewed Preprint posted": "2023-09-01"
"Sent for peer review": "2023-03-23"
"Posted to bioRxiv": "2023-01-30" (link: "Go to bioRxiv": "https://www.biorxiv.org/content/10.1101/2<IP_ADDRESS>5977v1/")
[PLACE PDF URL HERE WHEN AVAILABLE] See step 7
Step 1. Inform bioRxiv
Who can help: @QueenKraken, @nlisgo, @scottaubrey

[x] Manuscript is in data hub index (https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v1/by-publisher/elife/get-by-manuscript-id?manuscript_id=86899)

Step 2. Create preview of manuscript
Who can help: @fred-atherden, @nlisgo, @scottaubrey

[ ] Manuscript is available for preview (https://prod--epp.elifesciences.org/preview/86899/v1)

[ ] Trigger import for staging: https://prod--epp.elifesciences.org/import
[ ] Sync data folder with s3://prod-elife-epp-data/data
[ ] Trigger import for staging: https://staging--epp.elifesciences.org/import
[ ] Sync data folder with s3://staging-elife-epp-data/data
[ ] Pull request created to enhanced-preprint-data
[ ] Post link to pull request below

Pull request: [PLACE LINK TO PULL REQUEST HERE]
Detailed instructions: https://github.com/elifesciences/enhanced-preprints-data#add-a-manuscript
Step 3: Awaiting public reviews and QC
Who can help: Production team

[ ] QC passed or QC not needed

Who can help: Editorial team

[x] Public reviews available on sciety (https://sciety.org/articles/activity/10.1101/2<IP_ADDRESS>5977)
[x] Manuscript and editor details at the top of this issue (Supplied by Editorial team)
[ ] Reviews returned by EPP - https://prod--epp.elifesciences.org/api/reviewed-preprints/86899/v1/reviews

Example
"msas": "Genetics and Genomics", "Neuroscience"
"msid": "84628"
"version": "1"
"preprintDoi": "10.1101/2<IP_ADDRESS>4241"
"articleType": "Reviewed Preprint"
"status": "Published from the original preprint after peer review and assessment by eLife."

"Reviewed Preprint posted": "2023-01-02"
"Sent for peer review": "2022-10-28"
"Posted to bioRxiv": "2022-11-21" (link: "Go to bioRxiv": "https://www.biorxiv.org/content/10.1101/2<IP_ADDRESS>4241v1")

Editors:
Reviewing Editor
Michael B Eisen
University of California, Berkeley, United States
Senior Editor
Michael B Eisen
University of California, Berkeley, United States

Step 4: Modify manuscripts.json (no PDF)

[ ] Reviewed preprint is published to EPP (https://elifesciences.org/reviewed-preprints/86899)

[ ] Pull request created to enhanced-preprint-client
[ ] Pull request switched to "Ready for review"
[ ] Post link to pull request below

[ ] Request that a doi be registered

[ ] Post link to #enhanced-preprint comment below

Pull request: [PLACE LINK TO PULL REQUEST HERE]
#enhanced-preprint comment thread: [PLACE LINK TO COMMENT HERE]

Instructions to modify manuscripts.json

Visit: https://github.com/elifesciences/enhanced-preprints-client/actions/workflows/publish-manuscript.yaml
Click: Run workflow
Complete the form and click "Run workflow"
A successful run should result in a new pull request at https://github.com/elifesciences/enhanced-preprints-client/pulls
Open the pull request and click the "Ready for review" button to trigger tests
Once the tests pass and you are happy with the changes the PR can be merged

Example pull request: https://github.com/elifesciences/enhanced-preprints-client/pull/334/files
Once the pull request is merged in it should be available a few minutes later.

Request that a doi
Post the following in #enhanced-preprint:
@Fred can you register a doi for https://elifesciences.org/reviewed-preprints/86899

Step 5: Awaiting search reindex

[ ] Reviewed preprint is avaliable on journal homepage (https://elifesciences.org)

The search reindex is triggered once an hour. We need the reviewed preprint to be indexed as the search application serves the journal homepage.

Additional info
If needed, the jenkins pipeline to reindex search can be triggered sooner.
https://alfred.elifesciences.org/job/process/job/process-reindex-reviewed-preprints/

Step 6: Published! Request PDF generation

[ ] Post the link to the PDF url at the top of the issue

[ ] Post link to #enhanced-preprint comment below

#enhanced-preprint comment thread: [PLACE LINK TO COMMENT HERE]
Post the following to the #enhanced-preprint on slack:
@Ryan Dix-Peek please can you generate a PDF for https://elifesciences.org/reviewed-preprints/86899

Step 7: Introduce PDF to data folder and git repo

[ ] PDF is avaliable at https://github.com/elifesciences/enhanced-preprints-data/raw/master/data/86899/v1/86899-v1.pdf

Detailed instructions: https://github.com/elifesciences/enhanced-preprints-data#add-a-pdf
Step 8: Add PDF url to manuscripts.json

[ ] Reviewed preprint PDF is available for download (https://prod--epp.elifesciences.org/reviewed-preprints/86899)

[ ] Pull request created to enhanced-preprint-client
[ ] Pull request switched to "Ready for review"
[ ] Post link to pull request below

[PLACE LINK TO PULL REQUEST HERE]

Instructions to add PDF url to manuscripts.json

Visit: https://github.com/elifesciences/enhanced-preprints-client/actions/workflows/add-pdf-url-to-manuscript.yaml
Click: Run workflow
Complete the form and click "Run workflow"
A successful run should result in a new pull request at https://github.com/elifesciences/enhanced-preprints-client/pulls
Open the pull request and click the "Ready for review" button to trigger tests
Once the tests pass and you are happy with the changes the PR can be merged

Example pull request: https://github.com/elifesciences/enhanced-preprints-client/pull/397/files
Once the pull request is merged in it should be available a few minutes later.

Step 9: Done!

[ ] Kettle is on!

maths equation on eLife preprint displayed OK?

Nice spot @rkcook312.
In short - no, but we have to live with it.
The main problem is that bioRxiv capture equations as images. When these are inline it's quite difficult without knowing the content of the image what size to display them (it's also difficult when not inline, but less so).
The best way around this would be for bioRxiv to capture these in a machine readable format - something we hope they will in the near future (we can also look into ways to OCR these images).
In the meantime, we can expect some poorly sized inline equations - and we may be able to do more on the platform side of things to get these rendered in a more legible way. Since that's a platform based solution (e.g. CSS) it doesn't really affect the content, so I think we should proceed as is.
Hope that makes sense, but LMK if not!


Upgrade to Python 3.10

Upgrade project to Python 3.10.

@jiarui-lu2
Hey Jiarui Lu I see.. this PR is now going to merge. This is the time we should reopen our closed PR regarding AQT Module Import fix , which was closed due to min Python version support in Apple/axlearn.
PR: Fix Module Import
Thankyou;


⚠ Bofrost.lu has degraded performance

In c0142d0, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1165 ms

Resolved: Bofrost.lu performance has improved in 88c346f.


Kiwi group or forum?

Just converting my Specs from Cedar to Kiwi. . . . . is there a group or forum?
I'm looking for a nice way to to enum assertion:
//instead of haveCountOf, what's a nice way to match enum?
<EMAIL_ADDRESS>asProjectFileType] should] haveCountOf:SourceCodeHeader];

If the enums are integers, then you can just wrap them in theValue(myEnum) for use in assertions.

Thanks very much for the reply. I was able to work it out without too much hassle from reading the spec files.
It might also make it even easier by add some details about this to the Readme or Wiki?
On Feb 24, 2012, at 12:27 AM, Ben Scheirman wrote:

If the enums are integers, then you can just wrap them in theValue(myEnum) for use in assertions.

Reply to this email directly or view it on GitHub:
https://github.com/allending/Kiwi/issues/90#issuecomment-4139550

A little busy .... but it is a wiki :)

Sure thing - I'll add some details in the Wiki :)
Maybe the Readme too, in which case I'll send a pull request.
On Feb 24, 2012, at 8:20 AM, Allen Ding wrote:

A little busy .... but it is a wiki :)

Reply to this email directly or view it on GitHub:
https://github.com/allending/Kiwi/issues/90#issuecomment-4148917


Reproduce Billion Word benchmark for paper by Baevski and Auli, 2018.

There is only example on how to run for WikiText-103, but not Billion Word, for the adaptive input paper by Baevski and Auli, 2018.
There is a difference between the two, as Billion Word is of short sentences. Can anyone help out?

@alexeib

Would be interested in this too!

Also interested in the correct setting to reproduce the resutls.

This issue is still not resolved. There is no documentation on how to reproduce results on Billion Word benchamark for paper Baevski and Ali, 2018.


west.yml: Use SAME70 DFP version 2.4.166

This commit updates the hal_atmel entry in the west.yml to pull in the
SAME70 DFP version 2.4.166.
Signed-off-by: Stephanos Ioannidis<EMAIL_ADDRESS>NOTE: Do not merge until zephyrproject-rtos/hal_atmel#8 is merged and the module commit SHA in this PR is updated.

cc @nandojve

@mnkp are you ok with merging this?

@mnkp are you ok with merging this?

@mnkp ping

Sorry, didn't mean to block this. However, we still need to merge zephyrproject-rtos/hal_atmel#8.

Updated west.yml. This can be merged now.


2 warning messages at the terminal

There are 2 warning messages at the terminal while running, clearing these warnings could help a developer to see new error/warning messages easier.

Warning: Received true for a non-boolean attribute crossOrigin.
This one is from next.js google font loading

[next-auth][warn][NO_SECRET]
This one is from next-auth.js and warns about no defined random string secret for hashing tokens, sign/encrypt cookies
REF. https://next-auth.js.org/configuration/options#secret

To Reproduce
run npm run develop
Expected behavior
no warnings, clearly logging messages at the terminal
Screenshots
Warning: Received `true` for a non-boolean attribute `crossOrigin`.

If you want to write it to the DOM, pass a string instead: crossOrigin="true" or crossOrigin={value.toString()}.
    at link
    at head
    at Head (webpack-internal:///./node_modules/next/dist/pages/_document.js:239:1)
    at html
    at Html (webpack-internal:///./node_modules/next/dist/pages/_document.js:204:73)
    at MyDocument (webpack-internal:///./pages/_document.js:11:1)
[next-auth][warn][NO_SECRET]
https://next-auth.js.org/warnings#no_secret

It would be great if the maintainer could let me create a PR for this issue

@fahsujitra Sure, you're welcome to submit a PR for this.  Thanks for filing the issue.


[V5] no documentation for addField/removeField/swapField in API

just wanted to note that there's no clear documentation (that I can find) outside of the deepForms examples that explains addField/removeField/swapField

Yeah. It's mentioned on the Deep Form example, but not in the API section of the docs. I couldn't figure out where to put it. Maybe it needs its own page.

I was going to ask the same question.
Let's see if I got it right:

addArrayValue is a standalone function used to add a new array element to an existing form. The array to which the element is added need not exist (?) so I would assume in the following case:
addArrayValue('myForm', 'myElement[1].subElement');

then myElement[1] must already exist, but subElement need not exist.

addField, removeField and swapField are functions that are added to all the arrays in the form's state.

If there is no array to begin with, you need to call addArrayValue, then you can if you want call addField() on the newly created array. Or you can generate the entire array using addArrayValue.
I imagine that these methods dispatch actions which the redux-form reducer acts on.
let me know if any of this is right .. or wrong..

I can see where this would be confusing.

addField, removeField and swapField are functions that are added to all the arrays in the form's state.

Those are the only ones you really need to use. addArrayValue() is just the action creator that they use. So you could dispatch that action from outside your component (where you don't have access to this.props.fields), but you probably don't need to.
The process goes like this:

Have one of the fields in your fields config be an array (e.g. nicknames[] or addresses[].street for an array of subfields)
Place a button to add an entry to the array that calls this.props.fields.nickname.addField()
This makes this.props.fields.nickname.length === 1 so you can render <input {...this.props.fields.nickname[0]}/>

Does that clarify anything?

Yes it's clear now. Thanks!
And thank you for the feature itself. I was somewhat horrified today when I realized I hadn't planned for our forms to be "extensible". I thought I was going to need a major hack. Then I found out you had already solved the problem :-)

+1 for adding documentation for this. I couldn't not find anything in google search except for this post.

Closing with bulk close of v5 issues. If this issue still requires action and/or also affects v6/7, please request a reopen with details or raise a new issue. v5 PR's are still welcomed.


Confusing --admin-api-key flag

When installing the CLI and attempting to use it, the first thing the docs reference after installing the cli is to run algolia profile add which prompts for an admin api key (it seems excessive for a CLI tool to require an admin key). Since I'm not the application owner and do not have access to the admin key I tried to just use a write API key with hopes that I could still do operations for which the key has proper acl permissions. Tldr, algolia profile add requires the actual admin api key and the command fails with unauthorized key error.
This makes the experience seem like only application admins (or whoever can get their hands onto the admin api key) can use the CLI which contradicts what the docs say here

A command line interface to enable Algolia developers to interact with and configure their Algolia applications straight from a command...

So as as user, I tried to run algolia --help to try and understand if there are other ways I can use the CLI, but the only listed flags are
Flags:
      --admin-api-key string    The admin API key
      --application-id string   The application ID
  -h, --help                    help for algolia
  -p, --profile string          The profile to use
  -v, --version                 Get the version of the Algolia CLI

If it is true that the CLI requires and admin api key then the docs should be updated to reflect that. Imo asking for an admin api key is an overkill and encourages bad practices of sharing the admin api key. I did not end up using the CLI, but I would prefer if there was a way for me to run algolia ...commands --api-key=<whatever key> and have the key permissions checked by the engine for each operation that my CLI command is doing (which is assume is already the case anyways).

The purpose of the CLI is to administer the application isn't it?

@gregfenton IMO this is violating the security principle of least privilege.
E.g. If I'm not ever going use the cli tool to delete an index, I should be able to use a key that doesn't have delete index permissions.
It worsens the impact if one of the keys was to leak, and using shared credentials are bad for a number of reasons.
It looks like work has already been done to enable profiles without an admin key, could this be looked at? https://github.com/algolia/cli/pull/139

@JonasBa note you can use the algolia cli without an admin api key, if you use it without setting up a profile.
You can pass a non-admin credentials to the particular command with --admin-api-key $NON_ADMIN_KEY --application-id $APP_ID.

Thank you finding the right words for me @poida :)
@gregfenton, there are usually plenty of teams or individuals in the company with various levels of permissions. Forcing, or indicating to them that the correct way to use a tool like a CLI is to share a single admin key with root level permissions is security issue nightmare waiting to happen (I doubt any sane security process would allow this).
My take is that to use a tool like the CLI wrapper, which is just a convenient way of executing commands, a key with a min set of permissions to execute the action should be required. If what @poida is saying about bypassing the profile generation is true, then that contradict the notion of administering the application, as it sounds like the key permissions are not properly validated.

@gregfenton IMO this is violating the security principle of least privilege.
E.g. If I'm not ever going use the cli tool to delete an index, I should be able to use a key that doesn't have delete index permissions.

I fully agree.  I was commenting that my read of the docs is that the CLI is intended to be for "configuring and administering applications".  Though I see value in having the CLI commands available to lesser-enabled users, I didn't read that intent from the docs.  To me it read like an admin tool similar to what you get from many PaaS systems.
I am very glad to see work is underway to add more granularity to the functionality...though that PR is a huge change!

#139 should have solved the issue, we do now support non-admin API keys in the profile and as a flag :)


How click to control without mouse moving?

I use demo code from wiki. All work, but my mouse) Its manually moving it. I think this library use winapi and its can click on button without mouse moving...

There are multiple aspects here:

There is a boolean to define if the mouse should move slowly or instantly
If you use the mouse clicks the mouse always need to be at the position that should be clicked. There is no way around.
Maybe it us better if you use Invoke from the InvokePattern.

You can use WinAPI with SendMessage to fake clicks but then you could miss some events like mouse enter and such. I might think to add that as well but in general using patterns is better.

@Roemer  why you think that i miss mouse enter event?

Because this one is only fired when the mouse effectively moves over an element.

I did some more research (again) and the SendMessage method is very unreliable (see https://blogs.msdn.microsoft.com/oldnewthing/20050530-11/?p=35513). And the SendInput method (which is the best to simulate the mouse) does not allow to "send" to other windows than the foreground window.
If you need to click a button without moving the mouse, use the invoke method from the invoke pattern. If the element you want to click does not support the invoke pattern, use your own SendMessage for this and hope that it works. Since it's unreliable, I will not add this to the FlaUI base framework. Feel free to add more comments if you still have questions.


CupertinoPicker _buildMagnifierScreen() is drawing double border lines

See the lines above and below the 4 and the 25,
These lines only appear after scrolling the pickers. Not in their initial state
I currently have four Cupertino pickers side by side, with flex values 2,1,1,1
   child: new Row(                   children: <Widget>[                     new Flexible(                       flex: 2,                       child: Container(                         height: 140.0,                         child: new CupertinoPicker(                           useMagnifier: false,                           scrollController: new FixedExtentScrollController(                             initialItem: _selectedDay,                           ),                           itemExtent: 28.0,

Please add the output of flutter doctor -v.

Could you add some details on how to reproduce this issue? I couldn't produce it from your description from HEAD.

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.


Use NumPy 1.23 or earlier for testing

Skip using NumPy 1.24 in testing since this results in deprecation warnings that get turned into test failures. Instead use NumPy 1.23 or earlier, which do not have this issue.
xref: https://github.com/conda-forge/pandas-feedstock/issues/150

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

@conda-forge-admin, please re-render


Allow optional injections

It's done. Optional injections can be defined as:
type myStruct struct {
  Dep `injector:"dep,optional"
}


[Spark] Disable implicit casting in Delta streaming sink

Description
https://github.com/delta-io/delta/pull/3443 introduced implicit casting when writing to a Delta table using a streaming query.
We are disabling this change for now as it regresses behavior when a struct field is missing in the input data. This previously succeeded, filling the missing fields with null but would now fail with:
DELTA_UPDATE_SCHEMA_MISMATCH_EXPRESSION] Cannot cast struct<name:string> to struct<name:string,age:bigint>. All nested columns must match.

Note: batch INSERT fails in this scenario with:
[DELTA_INSERT_COLUMN_ARITY_MISMATCH] Cannot write to '<table>, not enough nested fields in <struct>; target table has 3 column(s) but the inserted data has 2 column(s)

but since streaming write allowed this, we have to preserve that behavior.
How was this patch tested?
Tests added as part of https://github.com/delta-io/delta/pull/3443, e.p. with flag disabled.
Does this PR introduce any user-facing changes?
Disabled behavior change that was to be introduced with https://github.com/delta-io/delta/pull/3443.

FWIW we noticed something similar recently with inserts on merge, the implicit cast failed if struct fields were missing

FWIW we noticed something similar recently with inserts on merge, the implicit cast failed if struct fields were missing

I believe that's expected in that case, unless you enable schema evolution, MERGE / UPDATE rejects writes with missing struct fields. Batch (non-streaming) INSERT also rejects that - although I've recently looked closer at batch insert behavior and the truth is that it's a bit all over the place..
Rejecting missing fields is a reasonable behavior when schema evolution is disabled, as it means we instead fall back to schema enforcement. Streaming writes didn't behave that way though, which I missed

Rejecting missing fields is a reasonable behavior when schema evolution is disabled, as it means we instead fall back to schema enforcement. Streaming writes didn't behave that way though, which I missed

This is missing fields in the source, not the target, so not schema evolution related.
Easy example:
import pyspark.sql.functions as F
from delta import DeltaTable
# Create table of nested struct<id: long, value: long>
spark.range(10).select(F.struct('id', (F.col('id') * 10).alias('value')).alias('nested')).write.format('delta').save('/tmp/merge-test')
# Works without "nested.value"
spark.range(10).select(F.struct('id').alias('nested')).write.format('delta').mode('append').save('/tmp/merge-test')

table = DeltaTable.forPath(spark, "/tmp/merge-test")
# Fails with "Cannot cast struct<id:bigint> to struct<id:bigint,value:bigint>. All nested columns must match
table.alias('target').merge(spark.range(20, 30).select(F.struct('id').alias('nested')).alias('source', 'target.nested.id = source.nested.id').whenNotMatchedInsertAll().execute()

Rejecting missing fields is a reasonable behavior when schema evolution is disabled, as it means we instead fall back to schema enforcement. Streaming writes didn't behave that way though, which I missed

This is missing fields in the source, not the target, so not schema evolution related.
Easy example:
import pyspark.sql.functions as F
from delta import DeltaTable
# Create table of nested struct<id: long, value: long>
spark.range(10).select(F.struct('id', (F.col('id') * 10).alias('value')).alias('nested')).write.format('delta').save('/tmp/merge-test')
# Works without "nested.value"
spark.range(10, 20).select(F.struct('id').alias('nested')).write.format('delta').mode('append').save('/tmp/merge-test')

table = DeltaTable.forPath(spark, "/tmp/merge-test")
# Fails with "Cannot cast struct<id:bigint> to struct<id:bigint,value:bigint>. All nested columns must match
table.alias('target').merge(spark.range(20, 30).select(F.struct('id').alias('nested')).alias('source', 'target.nested.id = source.nested.id').whenNotMatchedInsertAll().execute()

Right, save()/saveAsTable() will accept missing fields, but if you try SQL INSERT INTO t (nested) VALUES (..), then I expect that will fail. I think insert by position - df.insertInto(), INSERT INTO t VALUES (..) - will also fail.
We do handle SQL insert by name and SQL/DF insert by position in DeltaAnalysis and apply schema enforcement, but let save()/saveAsTable() get through unhandled and pretty much don't do any schema validation beyond basic compatibility when writing the data.
That's what I meant by insert behavior is a bit all over the place, I looked at it a couple of weeks ago to see if it could be fixed - and allow implicit casting in save()/saveAsTable() - but this would bring a lot of breaking behavior changes

That's what I meant by insert behavior is a bit all over the place, I looked at it a couple of weeks ago to see if it could be fixed - and allow implicit casting in save()/saveAsTable() - but this would bring a lot of breaking behavior changes

Would it make more sense to do a Dataset.to type operation instead of a cast? That seems more like what is trying to be achieved.

Would it make more sense to do a Dataset.to type operation instead of a cast? That seems more like what is trying to be achieved.

That seems too limited, Dataset.to also cast types and eventually calls to Cast.canANSIStoreAssign() which for example doesn't allow many casts that we do support today - we allow most or all valid implicit casts, string -> int would be valid - and doesn't respect the value of spark.sql.storeAssignmentPolicy that write operations should respect.
The column reordering part does make sense though, although the issue isn't so much how to apply it as much as making sure we're not breaking existing workloads if we start doing it in more cases

So it seems like the whole issue stems from the fact that castIfNeeded treats a missing source field as "schema evolution". But that is very different from what most would consider as "schema evolution", a missing field in the target, and the schema of the target table changing as a result of some sort of write. It's really "null filling". If you remove allowStructEvolution from castIfNeeded, and don't make it throw an exception if the source is missing a target field, that would likely resolve a lot of the issues/difference with the write paths, and make this sink cast a non-issue. If you really think null-filling should be configurable (whether defaulting to false or true), that should be a different setting than "schema merging", as the use case is very different.

So it seems like the whole issue stems from the fact that castIfNeeded treats a missing source field as "schema evolution". But that is very different from what most would consider as "schema evolution", a missing field in the target, and the schema of the target table changing as a result of some sort of write. It's really "null filling". If you remove allowStructEvolution from castIfNeeded, and don't make it throw an exception if the source is missing a target field, that would likely resolve a lot of the issues/difference with the write paths, and make this sink cast a non-issue. If you really think null-filling should be configurable (whether defaulting to false or true), that should be a different setting than "schema merging", as the use case is very different.

+1, I have it on my todo list to look into this. UpdateExpressionsSupport is historically the place that implements (part of) schema evolution/enforcement for MERGE and UPDATE, but the checks could be moved somewhere else and applied during analysis.

@Kimahriman I finally got around to implementing some of the changes we discussed previously
PR: https://github.com/delta-io/delta/pull/3822
I've asked @tomvanbussel to review it but you can also have a look if you'd like
E.p. castIfNeeded now uses allowMissingStructField instead of allowStructEvolution as a more accurate description of what the associated behavior is, and the fact that streaming writes actually allow missing struct fields even when schema evolution is disabled.
I'm still making that behavior configurable because we need to preserve existing behavior, and UPDATE/MERGE behave differently than streaming writes today (UPDATE/MERGE only allow missing struct fields when schema evolution is enabled)


Generalize folder flags

From SO request:

[ ] A flag under the Folder names, that would indicate that the folder images have been sent [...] for transcription
[ ] Possibly a flag that would indicate that the folder had been transcribed
[x] 'Ready for DAMS', etc, made generic

Badges have been implemented for folders. Closing.


Review updates: front end

Acceptance criteria

[x] Review block on submission detail page styled as per design:

[x] if reviewer assigned but no reviews or agreement/disagreement yet, display as per design (include icon) but greyed out as per current styles

[x] agreement/disagreement shown as 'Agree' or 'Disagree' associated with the parent review (coloured in green for agree, red for disagree)
[x] Traffic light to remain as per current design.

[x] Expanded submission on Submissions listing: agreement/disagreement shown in Review outcomes section as 'Agree' or 'Disagree' associated with the parent review. Styles based on review block on submission detail page
[x] Review detail view (e.g. https://dev-apply.opentech.fund/apply/submissions/11/reviews/4/): will show agreement/disagreement from anyone who has agreed or disagreed with the review in the header
[x] View all reviews view (e.g. https://dev-apply.opentech.fund/apply/submissions/6/reviews/) will show agreement/disagreement from anyone who has agreed or disagreed with the review in a new row above score in the table
[x] Error notifications styled as per standard notification styles. Try adding the same person as a primary and secondary review and see error notification that appears.

Design:

QA criteria
Dev:

[x] checked that this feature works across all agreed supported browsers and devices.
[x] checked that this code meets the agreed accessibility level.
[x] checked that this code meets the agreed browser performance levels.
[x] checked that this code conforms to the project coding standards.
[x] had code reviewed by another developer and resolved any issues raised.
[x] tested this feature as an end user.
[x] checked that the feature works on the server/s I am deploying it to.

QA:

[x] tested this feature as a front end user and it meets the acceptance criteria/conforms to the specification and design.
[x] checked that the feature works on the server/s deployed to

Blocked until BE work is complete and can be put on dev to test

One FE tweak required which I noticed as I tested #959:
Reviewer block on submission page: don't show the line underneath the reviewers if there are no AC reviewers (e.g. https://dev-apply.opentech.fund/apply/submissions/5/)

Hi @chris-lawton,
As I have been tested review stuff, I have noticed a small styling tweak required. On review pages, e.g. https://dev-apply.opentech.fund/apply/submissions/5/reviews/10/, when you use the agree button, the agree button should then be disabled when you return to it. And vice versa. This was in place, however something recently seems to have knocked this out. Can you please take a look?
Thanks,
Maya

Hi @gibbsmaya,
This and the disabled button styles are now on dev.
Thanks,
Chris

Hi @chris-lawton
All looks good - just one tweak: need some further styling on the expanded view of a submission in the submissions list - should be based on styles from review block on submission page so we can show relationship between reviews and agree/disagree.
Thanks.

Hi @gibbsmaya ,
The following are now on dev:

dropdown agree/disagree styles (https://dev-apply.opentech.fund/apply/submissions/)
reviewer icon if they've agreed (https://dev-apply.opentech.fund/apply/submissions/5/)
disabled batch action tooltips (https://dev-apply.opentech.fund/apply/submissions/all/)
blue bar on active submission listing should now be visible

Thanks,
Chris

All LGTM.

Hi @fourthletter, @danblah, @arduina,
This work is now ready for testing. This work is the styling work for the new review consensus workflow, covering styling tweaks for functionality built in #962.
Please test this against the acceptance criteria noted in the initial issue description.
Please let us know if anything is unclear or if you have any questions. Otherwise please provide feedback of any issues you find or if everything is working as expected, please confirm and we can get this work deployed to the live site and issue closed off.
Thanks,
Maya

All acceptance criteria visible and functional. Thanks!

Thanks @fourthletter. Handing over to @todd-dembrey ready for deployment to live.


Invalid csrf token in server action when used without a form

It is possible to use server actions without using forms. https://react.dev/reference/react/use-server#calling-a-server-action-outside-of-form
In this case it still makes a POST request but when I pass csrfToken or csrf_token, csrf check fails.
Looking at the request, it makes POST request with the following body:
[{"csrf_token":"AAidYJqD9YPPT5NRqWt0l+czE4APICWVe+SV7RoP"}]
But weirdly Content-Type header is set to text/plain;charset=UTF-8 for all server actions.
Tested with edge-csrf 1.0.7 and nextjs 14.0.4

Seems to work when only csrfToken is passed.
export async function serverAction(csrfToken: string) {}

It then ends up in payload as:
["AAg1YUx7lDpToYuW0s7vdHkne+NFJvLhRPYHHEx6"]

But passing anything else seems to fail.
type Params = {
  csrfToken: string
  somethingElse: string
}
export async function serverAction(params: Params) {}

It's sent as:
[{"csrfToken":"AAiTe2uMJZbfnS/RuvnplJeLw02Q3HC348FJrB/O","somethingElse":"test"}]

Thanks for the bug report and for triaging the problem! I think your diagnosis is correct: currently edge-csrf doesn't attempt to parse request bodies as JSON unless they specify json content in the Content-Type header so in the case of Server Actions with Content-Type: text/plain the entire request body is returned as the CSRF token:
https://github.com/amorey/edge-csrf/blob/main/src/util.ts#L85
which means Server Action requests will pass CSRF checks when you pass in the token as one single argument but not when there are multiple arguments or when your single argument is an object.
Let me think about how to fix the problem and get back to you.

One potential solution is to try parsing submission requests with Content-type: text/plain as JSON arrays and if they parse successfully then treat the first argument as the csrf token. Here's an example of what a server action and it's caller would look like with the solution described above:
// action.ts
'use server';

export default async function recordData(csrfToken: string, data: any) {
  console.log(`received data: ${JSON.stringify(data)}`);
}

// page.tsx
'use client';

import recordData from '../lib/actions';

export default function LikeButton() {
  const handleClick = async () => {
    const csrfResp = await fetch('/csrf-token');
    const { csrfToken } = await csrfResp.json();
    await recordData(csrfToken, { 'rand': Math.random() });
  };

  return (
    <>
      <button onClick={handleClick}>Click me</button>
    </>
  );
}

Here's an implementation of the solution described above: https://github.com/amorey/edge-csrf/tree/nfsa
Let me know what you think.

I think the arguments here csrfToken:string, data: any:
export default async function recordData(csrfToken: string, data: any) {
  console.log(`received data: ${JSON.stringify(data)}`);
}

violate the Next.js API. The arguments to server actions must be serializable by React as per https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions-and-mutations#behavior. Having multiple arguments violates this and any violates this. I think the action approach works better for forms.
But for JSON requests I think this approach should work:
  await fetch('/api/foo', {
    method: 'POST',
    body: JSON.stringify({
      ...data,
      csrf_token: csrfToken,
    }),
    headers: {
      "Content-Type": "application/json"
    }
  })

In the example above, data: any is just a Typescript placeholder that you should replace with your own more specific schema (e.g. data: { rand: number; }). In any case, the Server Action API requirement is that each argument must be serializable at runtime so the Typescript definitions in the source code are just acting as helpers. Here's an implementation of the example above that passes Typescript checks at compile time and also executes successfully without error at runtime:
https://github.com/amorey/edge-csrf/tree/nfsa/examples/next14-approuter-server-action-non-form-submission
With regards to JSON requests, if you want to use fetch() instead of a server action then you should add the token as an HTTP header:
await fetch('/api/foo', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-CSRF-Token': csrfToken,
  },
  body: JSON.stringify(data),
});

(See https://github.com/amorey/edge-csrf/tree/main/examples/next14-approuter-js-submission-static)

Is there a way to get this working with multipart form data? I'm currently using a server action without a form for uploading images, but with using the method above it makes working with images difficult. Currently I'm converting my images to a base64 string so I can send it through the server action, and then converting back to a blob in my server action.
const { data: flagData, error: imageUploadError } = await uploadImage(
				csrfToken,
				{
					blob: String(await blobToBase64(flagBlob)),
					name: data.name
				}
			)

Yes, it should work with the code in the "nfsa" branch. Try<EMAIL_ADDRESS>and see if that works:
https://www.npmjs.com/package/edge-csrf/v/1.0.7-nfsa.1

if I try to pass formData into my server action at it causes the server action to throw 403, but if I pass JSON serializable data it seems to work just fine.
I want to be able to do something like this:
const { data: flagData, error: imageUploadError } = await uploadImage(
    csrfToken,
    flagForm // type of FormData
)

Edge-CSRF already supports server actions with forms/formData in the latest release (edge-csrf@1.0.7). Take a look at the example app here:
https://github.com/amorey/edge-csrf/blob/main/examples/next14-approuter-server-action-submission
And in particular at the form submission implementation here:
https://github.com/amorey/edge-csrf/blob/main/examples/next14-approuter-server-action-submission/app/page.tsx
For forms, the CSRF token should be passed in as a hidden input with name csrf_token:
import { revalidatePath } from 'next/cache';
import { headers } from 'next/headers';
import { redirect } from 'next/navigation';

export default function Page() {
  const csrfToken = headers().get('X-CSRF-Token') || 'missing';

  async function myAction(formData: FormData) {
    'use server';
    console.log('passed csrf validation');
    revalidatePath('/');
    redirect('/');
  }

  return (
    <form action={myAction}>
      <legend>Form with CSRF (should succeed):</legend>
      <input type="hidden" name="csrf_token" value={csrfToken} />
      <input type="text" name="input1" />
      <button type="submit">Submit</button>
    </form>
  );
}

Let me know if that helps.

Thank you for the info. On my other server components that are using server actions directly the forms that is what I'm doing it and it works great. The issue I'm encountering is that I have a client side form using react-hook-forms. Within the onSubmit function I'm calling two server actions which both need the csrf token. Here's a link to the github code for my form code: https://github.com/Entropy-10/test-open-site/blob/main/app/[locale]/register/_components/create-team-form.tsx (this is my main branch without the edge-csrf code implemented).

Ahh I see, thanks for the explanation. I just tried it out and it looks like the request type changes from text/plain to multipart/form-data when one of the arguments is a FormData instance which means the request will be treaded like a server action form submission by edge-csrf. Try this:
// action.ts
'use server';

export default async function recordData(data: FormData) {
  console.log(data);
}

// page.tsx
'use client';

import recordData from '../lib/actions';

export default function LikeButton() {
  const handleClick = async () => {
    const csrfResp = await fetch('/csrf-token');
    const { csrfToken } = await csrfResp.json();

    const data = new FormData();
    data.set('csrf_token', csrfToken);
    data.set('var1', 'val1');

    await recordData(data);
  };

  return (
    <>
      <button onClick={handleClick}>Click me</button>
    </>
  );
}

Thank you so much that worked perfectly!

Great, happy to hear it!
With regards to the questions in the beginning of this thread, I merged the server action non-form handler code into main and published a new version (v1.0.8) so now those queries should work. I also added a list of all the examples to the README to help users looking for help in the future:
https://github.com/amorey/edge-csrf/tree/main


Add awareness features to handle server state

This PR adds the awareness class, extracted from https://github.com/jupyter-server/pycrdt-websocket.
This PR adds some features to that awareness to allow the server to update and observe it.

Also, we'll need 100% test coverage.

It should be OK now

@brichet I took the liberty to make some changes in https://github.com/jupyter-server/pycrdt/pull/170/commits/98540a57c78b63c6cfb6fc070a97df4b6d8d1692, please let me know if you agree with them.
Among other things, I removed the on_change() callback. The encoded state is just (optionally) returned when the local state is set. That lets the door open for emitting the encoded state in the future.

Thanks @davidbrochart, I can't make a proper review of you change now but I guess it will OK.
Let's move forward!

Among other things, I removed the on_change() callback. The encoded state is just (optionally) returned when the local state is set. That lets the door open for emitting the encoded state in the future.

No sure about that finally. How do you think the state will be emitted ?
Updating the awareness should be possible from a server extension, which means from a program that may not know how to emit a message, and that should probably not take care of it...
The on_change() callback allow to emit the change to all clients, whatever the source of the change.

I think there is some redundancy with observe() and on_change():

observe() allows to be notified with the deserialized (global) awareness changes.
on_change() allows to be notified with the serialized local awareness changes.

Also, observe() allows to register multiple callbacks, but on_change() allows to register only one callback.
I think we need to handle origins as it's done in awareness.js, where setLocalState() emits the deserialized changes with an origin set to 'local', which would correspond to calling our callbacks registered with observe(). This is the only callback mechanism we should have. The callbacks would receive the deserialized changes and the origin. If the origin is 'local', they could serialize the changes and send them to other peers.
So I think we should be closer to awareness.js and rename get_changes() to apply_awareness_update(), and have an encode_awareness_update() method for serializing changes.

Thanks for the suggestion, I can take a look at it..
Maybe we should keep the get_change() as deprecated to avoid backward incompatibility.

@davidbrochart I updated the class according to your suggestions, that should be closer to awareness.js now.

Thanks, do you mind if I take it from now? It will be quicker than requesting changes, and you will still be able to accept/reject my changes afterwards.

Does it work on your side ? I have errors when I try to use it:
      File "/home/brichet/projects/pycrdt/python/pycrdt/_awareness.py", line 136, in apply_awareness_update
        state_str = decoder.read_var_string()
                    ^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/home/brichet/projects/pycrdt/python/pycrdt/_sync.py", line 227, in read_var_string
        return message.decode("utf-8")
               ^^^^^^^^^^^^^^^^^^^^^^^
    UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc0 in position 0: invalid start byte

Do you have a reproducible example?

Does it work on your side ? I have errors when I try to use it:
      File "/home/brichet/projects/pycrdt/python/pycrdt/_awareness.py", line 136, in apply_awareness_update
        state_str = decoder.read_var_string()
                    ^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/home/brichet/projects/pycrdt/python/pycrdt/_sync.py", line 227, in read_var_string
        return message.decode("utf-8")
               ^^^^^^^^^^^^^^^^^^^^^^^
    UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc0 in position 0: invalid start byte

Do you have a reproducible example?

Not really, I have an environment with dev install of pycrdt, pycrdt_websocket, jupyter_collaboration and jupyter_ydoc. All these packages need to be updated to test it properly.
I'll try to figure out where the error come from.

Thanks @davidbrochart.
Does it work on your side ? I have errors when I try to use it:
      File "/home/brichet/projects/pycrdt/python/pycrdt/_awareness.py", line 136, in apply_awareness_update
        state_str = decoder.read_var_string()
                    ^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/home/brichet/projects/pycrdt/python/pycrdt/_sync.py", line 227, in read_var_string
        return message.decode("utf-8")
               ^^^^^^^^^^^^^^^^^^^^^^^
    UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc0 in position 0: invalid start byte

@davidbrochart it seems that we do not take into account the full length of the message (first integer), when encoding and decoding.
This call was removing the first integer, corresponding to the length in bytes of the message, but has been remove in a previous commit.
And when encoding, we should add the full length before returning the message (https://github.com/jupyter-server/pycrdt/pull/170/files#diff-d0908cdc750b8113ae6b4433e378db136aebe96a30e773aef2cf08313b6669d8R117), I observe the same error in console.

An alternative would be to pass from_message/to_message boolean parameters, that would do the extra work if True.

I can't see a use case where we need an 'incomplete' encoded awareness (without the length).
Maybe we don't have to mimic exactly what is done in awareness.js if it is not relevant.
Also the YMessageType is missing from the encoder, and again I don't really know when encode_awareness_update() can be called for another message type....

I think it's good to go, any objection to merge @brichet?

Yes, it looks good to me too.

Thanks @brichet.

Thanks for helping a lot on it @davidbrochart.

Released in v0.10.0.


fix helm execute persistent action

With (helm +childframe) in doom! section, without this patch
execute-persistent-action opens an extra non-child frame. This
doesn't play nicely with my tiling window manager.
This patch is taken from helm-posframe, and seems to fix it.

Good catch, thanks!


Be clear about line/char limits in posts

Kate found there are line and character limits. Perhaps we should put a little text box out there that gives a hint to what these are.

Text areas in forms now show char and line limits.


Pitching loaders and more complete loader support

This patch brings support for the following loader APIs and context variables:
Variables

[x] this.request
[x] this.context
[x] this.resourceQuery
[x] this.loaderIndex
[x] this.values injects into this.inputValues for succeeding loaders

Loader APIs

[x] this.resolve (the asynchronous version) for resolving modules
[x] this.emitWarning
[x] this.emitError
[x] this.addDependency
[x] this.addContextDependency
[x] this.clearDependencies

Pitching

[x] module.exports.pitch application
[x] this.data gets passed from the pitch phase to the normal phase
[x] remainingRequest and precedingRequest inputs to the pitch loaders

@trueter can you test this out against your SASS codebase? I've made a small example under examples/sass-loader and it seems to work. I also tried your own set-up with the following loader string and it compiled successfully:
var path = require('path');
var HappyPack = require('../../');

module.exports = {
  entry: path.resolve(__dirname, 'lib/index.scss'),

  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: '[name].js'
  },

  plugins: [
    new HappyPack({
      loaders: [ 'style!css?modules&importLoaders=2&sourceMap&localIdentName=[local]___[hash:base64:5]!autoprefixer?browsers=last 2 version!sass?outputStyle=expanded&sourceMap&' ],
      cache: false,
      threads: 2
    })
  ],

  module: {
    loaders: [
      {
        test: /\.scss$/,
        loader: path.resolve(__dirname, '../../loader')
      }
    ]
  }
};

Also, pinging @XVincentX and @texttechne to test if possible. I have not tried the ExtractTextPlugin yet, but the style!css!sass combo should hopefully be functional with this.
Thanks.

I'll be happy to try out this and let you know the results. Stay tuned.

I have tried this branch with tslint-loader, which registered as preLoader. It fails with:
/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyRPCHandler.js:60
  assert(activeLoaders.hasOwnProperty(id),
  ^
AssertionError: A loader RPC was dispatched to HappyLoader[1] but no such loader is active!
    at assertLoaderIsActive (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyRPCHandler.js:60:3)
    at Object.HappyRPCHandler.execute (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyRPCHandler.js:28:5)
    at ChildProcess.acceptMessageFromWorker (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyThread.js:54:27)
    at emitTwo (events.js:87:13)
    at ChildProcess.emit (events.js:172:7)
    at handleMessage (internal/child_process.js:695:10)
    at Pipe.channel.onread (internal/child_process.js:440:11)

@Strate can you share your webpack config?
I'm not sure about preLoaders/postLoaders, I know there isn't any code to explicitly support them :scream: webpack loaders are crazy...

@amireh you know, same thing happens even if I put tslint-loader as a normal loader. I'll prepare example repo bit later.

@Strate i did get tslint-loader to work both as a normal and a pre/post loader. Also tried out some options like emitErrors: true and it seems to be OK. See the example in https://github.com/amireh/happypack/pull/15/commits/b3086ecf98cfc3d7752f02123ee5385e782205cf under /examples/tslint-loader for what I used.
However, ts-loader doesn't work since it actually hacks into webpack's compiler.

@amireh Tried fresh vesrion of this branch, git same error. I'll dig into that.

Unfortunately I have not been able to look into. I promise I will.

While I can not provide you example repo, I produced some debugging by add console.trace calls to registerActiveLoader and unregisterActiveLoader, and this is output:
Trace: HappyRPCHandler.registerActiveLoader tslint
    at Object.HappyRPCHandler.registerActiveLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyRPCHandler.js:12:11)
    at Object.HappyLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyLoader.js:20:19)
    at WEBPACK_CORE_LOADER_EXECUTION (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:71)
    at runSyncOrAsync (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:93)
    at nextLoader (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:290:3)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:259:5
    at Storage.finished (/devel/src/hotfix/megaplan/front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:38:16)
    at /devel/src/hotfix/megaplan/front/node_modules/graceful-fs/graceful-fs.js:78:16
    at FSReqWrap.readFileAfterClose [as oncomplete] (fs.js:380:3)
Trace: HappyRPCHandler.registerActiveLoader tslint
    at Object.HappyRPCHandler.registerActiveLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyRPCHandler.js:12:11)
    at Object.HappyLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyLoader.js:20:19)
    at WEBPACK_CORE_LOADER_EXECUTION (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:71)
    at runSyncOrAsync (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:93)
    at nextLoader (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:290:3)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:259:5
    at Storage.finished (/devel/src/hotfix/megaplan/front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:38:16)
    at /devel/src/hotfix/megaplan/front/node_modules/graceful-fs/graceful-fs.js:78:16
    at FSReqWrap.readFileAfterClose [as oncomplete] (fs.js:380:3)
Trace: HappyRPCHandler.unregisterActiveLoader tslint
    at Object.HappyRPCHandler.unregisterActiveLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyRPCHandler.js:17:11)
    at /devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyLoader.js:33:21
    at EventEmitter.<anonymous> (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyPlugin.js:249:7)
    at emitOne (events.js:77:13)
    at EventEmitter.emit (events.js:169:7)
    at ChildProcess.acceptMessageFromWorker (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyThread.js:49:21)
    at emitTwo (events.js:87:13)
    at ChildProcess.emit (events.js:172:7)
    at handleMessage (internal/child_process.js:695:10)
    at Pipe.channel.onread (internal/child_process.js:440:11)
Trace: HappyRPCHandler.unregisterActiveLoader tslint
    at Object.HappyRPCHandler.unregisterActiveLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyRPCHandler.js:17:11)
    at /devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyLoader.js:33:21
    at EventEmitter.<anonymous> (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyPlugin.js:249:7)
    at emitOne (events.js:77:13)
    at EventEmitter.emit (events.js:169:7)
    at ChildProcess.acceptMessageFromWorker (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyThread.js:49:21)
    at emitTwo (events.js:87:13)
    at ChildProcess.emit (events.js:172:7)
    at handleMessage (internal/child_process.js:695:10)
    at Pipe.channel.onread (internal/child_process.js:440:11)
Trace: HappyRPCHandler.registerActiveLoader tslint
    at Object.HappyRPCHandler.registerActiveLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyRPCHandler.js:12:11)
    at Object.HappyLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyLoader.js:20:19)
    at WEBPACK_CORE_LOADER_EXECUTION (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:71)
    at runSyncOrAsync (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:93)
    at nextLoader (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:290:3)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:259:5
    at Storage.provide (/devel/src/hotfix/megaplan/front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:52:20)
    at CachedInputFileSystem.readFile (/devel/src/hotfix/megaplan/front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:140:24)
    at DependenciesBlock.onLoadPitchDone (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:255:7)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:182:27)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:186:21)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:223:61)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:186:21)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:223:61)
    at DependenciesBlock.doBuild (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:241:4)
    at DependenciesBlock.build (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModule.js:84:14)
    at Compilation.buildModule (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/Compilation.js:126:9)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/Compilation.js:309:10
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:58:13
    at NormalModuleFactory.applyPluginsAsyncWaterfall (/devel/src/hotfix/megaplan/front/node_modules/tapable/lib/Tapable.js:75:69)
    at onDoneResolving (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:38:11)
    at onDoneResolving (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:121:6)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:116:7
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:726:13
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:52:16
    at done (/devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:246:17)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:44:16
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:723:17
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:167:37
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:52:16
Trace: HappyRPCHandler.registerActiveLoader tslint
    at Object.HappyRPCHandler.registerActiveLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyRPCHandler.js:12:11)
    at Object.HappyLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyLoader.js:20:19)
    at WEBPACK_CORE_LOADER_EXECUTION (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:71)
    at runSyncOrAsync (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:93)
    at nextLoader (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:290:3)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:259:5
    at Storage.provide (/devel/src/hotfix/megaplan/front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:52:20)
    at CachedInputFileSystem.readFile (/devel/src/hotfix/megaplan/front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:140:24)
    at DependenciesBlock.onLoadPitchDone (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:255:7)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:182:27)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:186:21)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:223:61)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:186:21)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:223:61)
    at DependenciesBlock.doBuild (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:241:4)
    at DependenciesBlock.build (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModule.js:84:14)
    at Compilation.buildModule (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/Compilation.js:126:9)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/Compilation.js:309:10
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:58:13
    at NormalModuleFactory.applyPluginsAsyncWaterfall (/devel/src/hotfix/megaplan/front/node_modules/tapable/lib/Tapable.js:75:69)
    at onDoneResolving (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:38:11)
    at onDoneResolving (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:121:6)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:116:7
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:726:13
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:52:16
    at done (/devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:246:17)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:44:16
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:723:17
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:167:37
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:52:16
Trace: HappyRPCHandler.registerActiveLoader tslint
    at Object.HappyRPCHandler.registerActiveLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyRPCHandler.js:12:11)
    at Object.HappyLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyLoader.js:20:19)
    at WEBPACK_CORE_LOADER_EXECUTION (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:71)
    at runSyncOrAsync (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:93)
    at nextLoader (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:290:3)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:259:5
    at Storage.provide (/devel/src/hotfix/megaplan/front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:52:20)
    at CachedInputFileSystem.readFile (/devel/src/hotfix/megaplan/front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:140:24)
    at DependenciesBlock.onLoadPitchDone (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:255:7)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:182:27)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:186:21)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:223:61)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:186:21)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:223:61)
    at DependenciesBlock.doBuild (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:241:4)
    at DependenciesBlock.build (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModule.js:84:14)
    at Compilation.buildModule (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/Compilation.js:126:9)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/Compilation.js:309:10
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:58:13
    at NormalModuleFactory.applyPluginsAsyncWaterfall (/devel/src/hotfix/megaplan/front/node_modules/tapable/lib/Tapable.js:75:69)
    at onDoneResolving (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:38:11)
    at onDoneResolving (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:121:6)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:116:7
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:726:13
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:52:16
    at done (/devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:246:17)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:44:16
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:723:17
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:167:37
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:52:16
Trace: HappyRPCHandler.registerActiveLoader tslint
    at Object.HappyRPCHandler.registerActiveLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyRPCHandler.js:12:11)
    at Object.HappyLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyLoader.js:20:19)
    at WEBPACK_CORE_LOADER_EXECUTION (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:71)
    at runSyncOrAsync (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:93)
    at nextLoader (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:290:3)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:259:5
    at Storage.provide (/devel/src/hotfix/megaplan/front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:52:20)
    at CachedInputFileSystem.readFile (/devel/src/hotfix/megaplan/front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:140:24)
    at DependenciesBlock.onLoadPitchDone (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:255:7)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:182:27)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:186:21)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:223:61)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:186:21)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:223:61)
    at DependenciesBlock.doBuild (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:241:4)
    at DependenciesBlock.build (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModule.js:84:14)
    at Compilation.buildModule (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/Compilation.js:126:9)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/Compilation.js:309:10
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:58:13
    at NormalModuleFactory.applyPluginsAsyncWaterfall (/devel/src/hotfix/megaplan/front/node_modules/tapable/lib/Tapable.js:75:69)
    at onDoneResolving (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:38:11)
    at onDoneResolving (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:121:6)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:116:7
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:726:13
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:52:16
    at done (/devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:246:17)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:44:16
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:723:17
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:167:37
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:52:16
Trace: HappyRPCHandler.registerActiveLoader tslint
    at Object.HappyRPCHandler.registerActiveLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyRPCHandler.js:12:11)
    at Object.HappyLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyLoader.js:20:19)
    at WEBPACK_CORE_LOADER_EXECUTION (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:71)
    at runSyncOrAsync (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:93)
    at nextLoader (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:290:3)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:259:5
    at Storage.provide (/devel/src/hotfix/megaplan/front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:52:20)
    at CachedInputFileSystem.readFile (/devel/src/hotfix/megaplan/front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:140:24)
    at DependenciesBlock.onLoadPitchDone (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:255:7)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:182:27)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:186:21)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:223:61)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:186:21)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:223:61)
    at DependenciesBlock.doBuild (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:241:4)
    at DependenciesBlock.build (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModule.js:84:14)
    at Compilation.buildModule (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/Compilation.js:126:9)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/Compilation.js:309:10
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:58:13
    at NormalModuleFactory.applyPluginsAsyncWaterfall (/devel/src/hotfix/megaplan/front/node_modules/tapable/lib/Tapable.js:75:69)
    at onDoneResolving (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:38:11)
    at onDoneResolving (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:121:6)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:116:7
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:726:13
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:52:16
    at done (/devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:246:17)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:44:16
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:723:17
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:167:37
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:52:16
Trace: HappyRPCHandler.registerActiveLoader tslint
    at Object.HappyRPCHandler.registerActiveLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyRPCHandler.js:12:11)
    at Object.HappyLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyLoader.js:20:19)
    at WEBPACK_CORE_LOADER_EXECUTION (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:71)
    at runSyncOrAsync (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:93)
    at nextLoader (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:290:3)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:259:5
    at Storage.provide (/devel/src/hotfix/megaplan/front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:52:20)
    at CachedInputFileSystem.readFile (/devel/src/hotfix/megaplan/front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:140:24)
    at DependenciesBlock.onLoadPitchDone (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:255:7)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:182:27)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:186:21)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:223:61)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:186:21)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:223:61)
    at DependenciesBlock.doBuild (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:241:4)
    at DependenciesBlock.build (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModule.js:84:14)
    at Compilation.buildModule (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/Compilation.js:126:9)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/Compilation.js:309:10
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:58:13
    at NormalModuleFactory.applyPluginsAsyncWaterfall (/devel/src/hotfix/megaplan/front/node_modules/tapable/lib/Tapable.js:75:69)
    at onDoneResolving (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:38:11)
    at onDoneResolving (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:121:6)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:116:7
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:726:13
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:52:16
    at done (/devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:246:17)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:44:16
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:723:17
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:167:37
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:52:16
Trace: HappyRPCHandler.registerActiveLoader tslint
    at Object.HappyRPCHandler.registerActiveLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyRPCHandler.js:12:11)
    at Object.HappyLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyLoader.js:20:19)
    at WEBPACK_CORE_LOADER_EXECUTION (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:71)
    at runSyncOrAsync (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:93)
    at nextLoader (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:290:3)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:259:5
    at Storage.provide (/devel/src/hotfix/megaplan/front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:52:20)
    at CachedInputFileSystem.readFile (/devel/src/hotfix/megaplan/front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:140:24)
    at DependenciesBlock.onLoadPitchDone (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:255:7)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:182:27)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:186:21)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:223:61)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:186:21)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:223:61)
    at DependenciesBlock.doBuild (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:241:4)
    at DependenciesBlock.build (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModule.js:84:14)
    at Compilation.buildModule (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/Compilation.js:126:9)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/Compilation.js:309:10
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:58:13
    at NormalModuleFactory.applyPluginsAsyncWaterfall (/devel/src/hotfix/megaplan/front/node_modules/tapable/lib/Tapable.js:75:69)
    at onDoneResolving (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:38:11)
    at onDoneResolving (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:121:6)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:116:7
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:726:13
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:52:16
    at done (/devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:246:17)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:44:16
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:723:17
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:167:37
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:52:16
Trace: HappyRPCHandler.registerActiveLoader tslint
    at Object.HappyRPCHandler.registerActiveLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyRPCHandler.js:12:11)
    at Object.HappyLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyLoader.js:20:19)
    at WEBPACK_CORE_LOADER_EXECUTION (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:71)
    at runSyncOrAsync (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:93)
    at nextLoader (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:290:3)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:259:5
    at Storage.provide (/devel/src/hotfix/megaplan/front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:52:20)
    at CachedInputFileSystem.readFile (/devel/src/hotfix/megaplan/front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:140:24)
    at DependenciesBlock.onLoadPitchDone (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:255:7)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:182:27)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:186:21)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:223:61)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:186:21)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:223:61)
    at DependenciesBlock.doBuild (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:241:4)
    at DependenciesBlock.build (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModule.js:84:14)
    at Compilation.buildModule (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/Compilation.js:126:9)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/Compilation.js:309:10
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:58:13
    at NormalModuleFactory.applyPluginsAsyncWaterfall (/devel/src/hotfix/megaplan/front/node_modules/tapable/lib/Tapable.js:75:69)
    at onDoneResolving (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:38:11)
    at onDoneResolving (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:121:6)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:116:7
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:726:13
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:52:16
    at done (/devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:246:17)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:44:16
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:723:17
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:167:37
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:52:16
Trace: HappyRPCHandler.registerActiveLoader tslint
    at Object.HappyRPCHandler.registerActiveLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyRPCHandler.js:12:11)
    at Object.HappyLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyLoader.js:20:19)
    at WEBPACK_CORE_LOADER_EXECUTION (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:71)
    at runSyncOrAsync (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:93)
    at nextLoader (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:290:3)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:259:5
    at Storage.provide (/devel/src/hotfix/megaplan/front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:52:20)
    at CachedInputFileSystem.readFile (/devel/src/hotfix/megaplan/front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:140:24)
    at DependenciesBlock.onLoadPitchDone (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:255:7)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:182:27)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:186:21)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:223:61)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:186:21)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:223:61)
    at DependenciesBlock.doBuild (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:241:4)
    at DependenciesBlock.build (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModule.js:84:14)
    at Compilation.buildModule (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/Compilation.js:126:9)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/Compilation.js:309:10
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:58:13
    at NormalModuleFactory.applyPluginsAsyncWaterfall (/devel/src/hotfix/megaplan/front/node_modules/tapable/lib/Tapable.js:75:69)
    at onDoneResolving (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:38:11)
    at onDoneResolving (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:121:6)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:116:7
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:726:13
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:52:16
    at done (/devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:246:17)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:44:16
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:723:17
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:167:37
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:52:16
Trace: HappyRPCHandler.registerActiveLoader tslint
    at Object.HappyRPCHandler.registerActiveLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyRPCHandler.js:12:11)
    at Object.HappyLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyLoader.js:20:19)
    at WEBPACK_CORE_LOADER_EXECUTION (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:71)
    at runSyncOrAsync (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:155:93)
    at nextLoader (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:290:3)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:259:5
    at Storage.provide (/devel/src/hotfix/megaplan/front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:52:20)
    at CachedInputFileSystem.readFile (/devel/src/hotfix/megaplan/front/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:140:24)
    at DependenciesBlock.onLoadPitchDone (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:255:7)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:182:27)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:186:21)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:223:61)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:186:21)
    at DependenciesBlock.loadPitch (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:223:61)
    at DependenciesBlock.doBuild (/devel/src/hotfix/megaplan/front/node_modules/webpack-core/lib/NormalModuleMixin.js:241:4)
    at DependenciesBlock.build (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModule.js:84:14)
    at Compilation.buildModule (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/Compilation.js:126:9)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/Compilation.js:309:10
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:58:13
    at NormalModuleFactory.applyPluginsAsyncWaterfall (/devel/src/hotfix/megaplan/front/node_modules/tapable/lib/Tapable.js:75:69)
    at onDoneResolving (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:38:11)
    at onDoneResolving (/devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:121:6)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/lib/NormalModuleFactory.js:116:7
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:726:13
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:52:16
    at done (/devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:246:17)
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:44:16
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:723:17
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:167:37
    at /devel/src/hotfix/megaplan/front/node_modules/webpack/node_modules/async/lib/async.js:52:16
Trace: HappyRPCHandler.unregisterActiveLoader tslint
    at Object.HappyRPCHandler.unregisterActiveLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyRPCHandler.js:17:11)
    at /devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyLoader.js:33:21
    at EventEmitter.<anonymous> (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyPlugin.js:249:7)
    at emitOne (events.js:77:13)
    at EventEmitter.emit (events.js:169:7)
    at ChildProcess.acceptMessageFromWorker (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyThread.js:49:21)
    at emitTwo (events.js:87:13)
    at ChildProcess.emit (events.js:172:7)
    at handleMessage (internal/child_process.js:695:10)
    at Pipe.channel.onread (internal/child_process.js:440:11)

/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyRPCHandler.js:62
  assert(activeLoaders.hasOwnProperty(id),
  ^
AssertionError: A loader RPC (addDependency) was dispatched to HappyLoader[tslint] but no such loader is active!
    at assertLoaderIsActive (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyRPCHandler.js:62:3)
    at Object.HappyRPCHandler.execute (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyRPCHandler.js:30:5)
    at ChildProcess.acceptMessageFromWorker (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyThread.js:54:27)
    at emitTwo (events.js:87:13)
    at ChildProcess.emit (events.js:172:7)
    at handleMessage (internal/child_process.js:695:10)
    at Pipe.channel.onread (internal/child_process.js:440:11)

As you see, there is a lot of registerActiveLoader calls, just one unregisterActiveLoader call and error right after that call. Reducing threads even to 1 does not helps. Seems this could be reproduced with multiple files in test repo.

@Strate I was able to reproduce that case, although unreliably. However, the last patch should fix it in that the happy loader instances will not overwrite each other as targets for an RPC.
My guess is that this happens when webpack attempts to compile multiple files in parallel (probably using async.map or such), where more than one HappyLoader instance - identified by the same plugin ID - clobber each other. Now, we identify the loaders using both the plugin id and the resource they're handling. If this creeps up again, UUIDs can be used instead but I doubt it will be necessary.
Let me know if that fixes it.

@amireh I'll try it on weekend, thank you a lot, man!

@amireh Everything is ok with tslint-loader, thank you a lot man! Tested on 8 threads.

I have tried happypacked tslint-loader together with watch mode, and there is an issue while file change triggered:
ERROR in ./src/bums/common/autocomplete/containers/CAutocomplete.tsx
Module build failed: Error: TypeError: Cannot read property '_sendMessage' of undefined
    at /devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyLoader.js:37:23
    at HappyPlugin.<anonymous> (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyPlugin.js:268:14)
    at /devel/src/hotfix/megaplan/front/node_modules/happypack/lib/applyLoaders.js:266:16
    at applySyncOrAsync (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/applyLoaders.js:347:5)
    at apply (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/applyLoaders.js:264:5)
    at /devel/src/hotfix/megaplan/front/node_modules/happypack/lib/applyLoaders.js:127:7
    at applyPitchLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/applyLoaders.js:180:14)
    at applyPitchLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/applyLoaders.js:188:14)
    at applyPitchLoaders (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/applyLoaders.js:218:4)
    at Object.applyLoaders (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/applyLoaders.js:112:3)
    at HappyPlugin.compileInForeground (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyPlugin.js:266:16)
    at HappyPlugin.compile (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyPlugin.js:219:17)
    at Object.HappyLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyLoader.js:23:14)
 @ ./src/bums/common/example/Example.tsx 19:21-85

Seems that you need to test watch mode also.

And there is another thing: usgin tslint laoder with cache enabled does not produce any warning and error if cache used. Seems that all calls to emitWarning and similar should be cached also.

@Strate watch mode should be functional in the last patch, but the caching of loaders like tslint is gonna take more work so I'll leave it for the future.

@amireh I have updated happypack to #57a27045ea5c25fd65e6234a1c2350df8ddf8694 and it is still fails:
ERROR in ./src/lib/components/CSelect/CSelect.tsx
Module build failed: Error: loader._compiler._sendMessage is not a function
TypeError: loader._compiler._sendMessage is not a function
    at Object.HappyFakeLoaderContext.loader.addDependency (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyFakeLoaderContext.js:54:22)
    at Object.loadRelativeConfig (/devel/src/hotfix/megaplan/front/node_modules/tslint-loader/index.js:26:10)
    at Object.module.exports (/devel/src/hotfix/megaplan/front/node_modules/tslint-loader/index.js:150:35)
    at applySyncOrAsync (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/applyLoaders.js:336:21)
    at apply (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/applyLoaders.js:265:5)
    at /devel/src/hotfix/megaplan/front/node_modules/happypack/lib/applyLoaders.js:128:7
    at applyPitchLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/applyLoaders.js:181:14)
    at applyPitchLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/applyLoaders.js:189:14)
    at applyPitchLoaders (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/applyLoaders.js:219:4)
    at applyLoaders (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/applyLoaders.js:113:3)
    at HappyWorker.compile (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyWorker.js:28:3)
    at HappyPlugin._performCompilationRequest (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyPlugin.js:259:10)
    at HappyPlugin.compileInForeground (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyPlugin.js:250:8)
    at HappyPlugin.compile (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyPlugin.js:225:17)
    at Object.HappyLoader (/devel/src/hotfix/megaplan/front/node_modules/happypack/lib/HappyLoader.js:23:14)
 @ ./src/lib/components.ts 115:15-54