IntervalTree object has no attribute 'search

Dear Falcon team,
I have the following error while running unzip.py :
AttributeError: 'IntervalTree' object has no attribute 'search'
WARNING:root:Call '/bin/bash user_script.sh' returned 256.
WARNING:root:CD: 'uow-00' -> '/media/vol2/scratch/lcornet/cassava/falcon-test/3-unzip/0-phasing/001666F'
Traceback (most recent call last):
File "/media/vol2/home/lcornet/anaconda2/envs/denovo_asm/lib/python2.7/runpy.py", line 174, in _run_module_as_main
"main", fname, loader, pkg_name)
File "/media/vol2/home/lcornet/anaconda2/envs/denovo_asm/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File "/media/vol2/home/lcornet/anaconda2/envs/denovo_asm/lib/python2.7/site-packages/falcon_kit/mains/generic_run_units_of_work.py", line 11
6, in
main()
File "/media/vol2/home/lcornet/anaconda2/envs/denovo_asm/lib/python2.7/site-packages/falcon_kit/mains/generic_run_units_of_work.py", line 11
2, in main
run(**vars(args))
File "/media/vol2/home/lcornet/anaconda2/envs/denovo_asm/lib/python2.7/site-packages/falcon_kit/mains/generic_run_units_of_work.py", line 65
, in run
pypeflow.do_task.run_bash(script, inputs, outputs, params)
File "/media/vol2/home/lcornet/anaconda2/envs/denovo_asm/lib/python2.7/site-packages/pypeflow/do_task.py", line 187, in run_bash
util.system(cmd)
File "/media/vol2/home/lcornet/anaconda2/envs/denovo_asm/lib/python2.7/site-packages/pypeflow/io.py", line 29, in syscall
raise Exception(msg)
Exception: Call '/bin/bash user_script.sh' returned 256.
i tried to install Intervaltree with pip wihout success , could you help me ?

Ok, thanks Ivan.
Could you point me to a specific version ?
Luc,

Sure, can you test out version 2.1.0?
Best regards,
Ivan.

i already try :
pip install intervaltree==2.1.0
I can downgrade, but it will give the same result, no ?

Strange, perhaps it's picking up the intervaltree package from a different location?
Did you have the conda environment activated before you installed this version of intervaltree?
According to the docs, this version should contain the search function:
https://pypi.org/project/intervaltree/2.1.0/
Ivan

pip install intervaltree==2.1.0 wthin conda fix it,
Thanks

The latest pb-falcon/pb-assembly should also take care of this now. conda update --all


Fix for the issue of selectively disabling start or end date

#593
The above mentioned issue is fixed by introducing a new prop into the DateRangePicker component: selectivelyDisable. selectivelyDisable is a string proptype,which is none by default,but if defined as 'startDate' in DateRangePickerWrapper it disables the start-date and so is the case with end-date.

Coverage increased (+0.02%) to 86.15% when pulling 43174a7146b1dfd93409e22f038485bbc6d34cab on dart-wakar:selectiveDisable into 8eca5d0aeb00e22e92a1232de923408572dd0e96 on airbnb:master.

Coverage increased (+0.02%) to 86.15% when pulling 43174a7146b1dfd93409e22f038485bbc6d34cab on dart-wakar:selectiveDisable into 8eca5d0aeb00e22e92a1232de923408572dd0e96 on airbnb:master.

Coverage increased (+0.02%) to 86.15% when pulling b958ad36d4a8db86e8c39db8c351db93c9af3ddf on dart-wakar:selectiveDisable into 8eca5d0aeb00e22e92a1232de923408572dd0e96 on airbnb:master.

Coverage increased (+0.02%) to 86.15% when pulling 6b975bd5078efa984a29ec9b855d9a7633b1ffe2 on dart-wakar:selectiveDisable into 8eca5d0aeb00e22e92a1232de923408572dd0e96 on airbnb:master.

Coverage increased (+0.02%) to 86.15% when pulling 149009136b08e57c982d64d0bec34b4e22b1837c on dart-wakar:selectiveDisable into 8eca5d0aeb00e22e92a1232de923408572dd0e96 on airbnb:master.

Is there anything I can do to help get this merged? It would be very useful for a project I'm currently working on.

If you'd like to take over this PR @dart-wakar, that would be great.
I think that I'd personally prefer to roll this functionality up into the disabled prop and have it be able to be equal to true, false, 'startDate' or 'endDate'. I'd also like to see the prop type definition use the constants instead of hardcoding the strings.
what do you think @ljharb? i know you had some comments on the original PR.

I agree on constants; but I’m hesitant to roll up more meaning into an existing prop - but maybe it makes sense here for “disabled”.
If @ajwild or anyone else wants to update this PR, please comment here with a link to your branch and we can pull in the commits and rebase for you (rather than making a new PR).

@majapw @ljharb I've added a commit to the master branch of my fork: https://github.com/ajwild/react-dates
I had to pass through the disabled property from DateRangePicker to DayPickerRangeController to avoid updating or focusing on a disabled date when clicking on a calendar date.
It's also necessary to provide an isOutsideRange function to get the blocked-out-of-range CSS classes on the calendar, but the functionality still works without this. I think it would be messy trying to do this by updating the default isOutsideRange function.
Let me know if there's anything else required once you've had a chance to review/test it.

Awesome @ajwild I'll pull it into this branch and take a look. Thank you for the work!
Can you clarify a bit about what you mean here? I'm not sure I understand.

It's also necessary to provide an isOutsideRange function to get the blocked-out-of-range CSS classes on the calendar, but the functionality still works without this. I think it would be messy trying to do this by updating the default isOutsideRange function.

Sorry if I wasn't clear, I was referring to the "greyed-out" effect on the calendar dates.
Here's the code from the stories I added:
  .addWithInfo('disabled start date', () => (
    <DateRangePickerWrapper
      initialStartDate={moment().add(3, 'months')}
      initialEndDate={moment().add(3, 'months').add(10, 'days')}
      disabled="startDate"
      isOutsideRange={day => !isInclusivelyAfterDay(day, moment().add(3, 'months'))}
    />
  ))
  .addWithInfo('disabled end date', () => (
    <DateRangePickerWrapper
      initialStartDate={moment().add(3, 'months')}
      initialEndDate={moment().add(3, 'months').add(10, 'days')}
      disabled="endDate"
      isOutsideRange={day => !isInclusivelyAfterDay(day, moment()) ||
        !isInclusivelyBeforeDay(day, moment().add(3, 'months').add(10, 'days'))}
    />
  ))

A screenshot of the "disabled end date" example without isOutsideRange:

A screenshot of the "disabled end date" example with isOutsideRange:

Ah @ajwild you are right. I think we want to leave it up to the developer to block out days when disabling if that's the UI they want. I don't think we should make any attempt to mess with it automagically.


Internal Server Error with Bootstrap

@bbenezech I'm getting the following error on Heroku since you've merge the bootstrap branch into master.
2011-10-05T19:02:26+00:00 app[web.1]: ActionView::Template::Error (File to import not found or unreadable: bootstrap/variables.
2011-10-05T19:02:26+00:00 app[web.1]: Load path: /app
2011-10-05T19:02:26+00:00 app[web.1]:   (in /app/vendor/bundle/ruby/1.9.1/bundler/gems/rails_admin-ce9ca13f9664/app/assets/stylesheets/rails_admin/imports.css.scss.erb)):
2011-10-05T19:02:26+00:00 app[web.1]:     5:     %meta{:content => "text/html; charset=utf-8", "http-equiv" => "Content-Type"}
2011-10-05T19:02:26+00:00 app[web.1]:     6:     %meta{:content => "NONE,NOARCHIVE", :name => "robots"}
2011-10-05T19:02:26+00:00 app[web.1]:     7:     = csrf_meta_tag
2011-10-05T19:02:26+00:00 app[web.1]:     8:     = stylesheet_link_tag "rails_admin/rails_admin.css"
2011-10-05T19:02:26+00:00 app[web.1]:     9:     = javascript_include_tag "rails_admin/rails_admin.js"
2011-10-05T19:02:26+00:00 app[web.1]:     10:   %body.rails_admin{:style => "padding-top: 60px;"}
2011-10-05T19:02:26+00:00 app[web.1]:     11:     .topbar-wrapper{:style => "z-index: 5;"}

Can you play with bbenezech/dummy_app ?
I just tested it against latest RA~HEAD (local/dev) and deployed (Heroku/prod), no issue.
I guess it has something to do with config files in environnement, but I'm 100% cargo-culting on this.

I'm having this error too.
Sass::SyntaxError: File to import not found or unreadable: bootstrap/variables.
GET appname.herokuapp.com/assets/rails_admin/rails_admin.css dyno=web.1 queue=0 wait=0ms service=13ms status=304 bytes=0
Load path: /app
(in /app/vendor/bundle/ruby/1.9.1/bundler/gems/rails_admin-2b280bc600c9/app/assets/stylesheets/rails_admin/imports.css.scss.erb)
Served asset /rails_admin/rails_admin.css - 500 Internal Server Error

It only fails in Heroku, It works locally, and rake assets:precompile works as well.
I have gem 'bootstrap-sass', '1.3.0' in my Gemfile and config.assets.compile = true in production.rb
Not sure if it's related but I also have this warning just before the error:
Started GET "/assets/rails_admin/rails_admin.css" for <IP_ADDRESS> at 2011-10-07 21:40:35 +0000
WARNING:
Comments will evaluate the contents of interpolations (#{ ... }) in Sass 3.2.
On line 3 of '/app/vendor/bundle/ruby/1.9.1/bundler/gems/rails_admin-2b280bc600c9/app/assets/stylesheets/rails_admin/imports.css.scss.erb'
Please escape the interpolation by adding a backslash before the `#`.

The dummy_app works because it doesn't have any configurations in rails_admin.rb initializer. When I comment out the config.model call then everything works as advertised. I didn't get a chance to see what causes this behavior. I was able to push to Heroku with the stuff commented out and then uncomment it and then push again. This just in case you have to get it up there.

same over here:
2011-10-11T01:31:48+00:00 app[web.1]: WARNING: 2011-10-11T01:31:48+00:00 app[web.1]: On line 3 of '/app/vendor/bundle/ruby/1.9.1/bundler/gems/rails_admin-de689c4b18f6/app/assets/stylesheets/rails_admin/imports.css.scss.erb' 2011-10-11T01:31:48+00:00 app[web.1]: Comments will evaluate the contents of interpolations (#{ ... }) in Sass 3.2. 2011-10-11T01:31:48+00:00 app[web.1]:  2011-10-11T01:31:48+00:00 app[web.1]: Please escape the interpolation by adding a backslash before the #. 2011-10-11T01:31:48+00:00 app[web.1]:  2011-10-11T01:31:48+00:00 app[web.1]: ActionView::Template::Error (File to import not found or unreadable: bootstrap/variables.
btw, I'd love to see version tags & rubygem support since I'd really love to go back to the version that worked. since I'd really really love to have a working backoffice in production on heroku ;-).
srsly, what's the reason for the lack of versioning?
sven

RA is not stable, there is no gem release for the moment. Use branches or shas.
About the pb, you can also precompile your assets locally and version them.
That's what I use to deploy bbenezech/dummy_app on Heroku:
alias deploy_dummy="cd ~/ruby/dummy_app ; bundle update; RAILS_ENV=production bundle exec rake assets:precompile ; git add . ; git commit -m 'pushing to heroku' ; git push heroku master --force ; open http://rails-admin-tb.herokuapp.com/"

I'm getting the error on local and non-heroku production server (using HEAD and rails 3.1.1 final):
An err has just occurred in staging: Sass::SyntaxError: File to import not found or unreadable: bootstrap/variables.
Load path: /var/www/html/integration/mh/releases/20111011133022
 (in /var/www/html/integration/mh/shared/bundle/ruby/1.9.1/bundler/gems/rails_admin-aa2f2b9ce320/app/assets/stylesheets/rails_admin/imports.css.scss.erb)

 [GEM_ROOT]/bundler/gems/rails_admin-aa2f2b9ce320/app/assets/stylesheets/rails_admin/imports.css.scss.erb:15
 [GEM_ROOT]/gems/sass-3.1.10/lib/sass/tree/import_node.rb:64
...

For anyone getting the error who needs to back up versions until it's fixed changing the rails_admin line in your Gemfile to this and redoing you bundle should do the trick:
gem 'rails_admin', :git => 'git://github.com/sferik/rails_admin.git', :ref => '4367490cb311ff61c8d4b721bf98748397374dc2'
On a side note until there is versioning you can create your own unchanging version using the same method by setting "ref" to a check in number you are comfortable using.

@bbenezech oh I see - looked quire mature already ;-)
@rosew & @bbenezech thanks for the valuable advices, local asset generation & using the shas as versions would be sufficient alternatives to my approach

Can you guys have a look with latest HEAD 20c41fbc1863878a7749ad56f20e11ccbf761e42 ?
I added a hook to compile
rails_admin/rails_admin.{css/js}

Without it I guess sprockets blows when assets.compile is false. (rails_admin assets were not added to public/assets with rake assets:precompile in main_app)

The latest commit didn't fix it for me, this is with gem 'bootstrap-sass', '1.3.0' and config.assets.compile = true

For those of you who have problem on heroku, please read http://devcenter.heroku.com/articles/rails31_heroku_cedar
@sferik I solved the File to import not found or unreadable: bootstrap/variables bug with
config.assets.initialize_on_precompile = false
I'm investigating to find out why.

Hi,
didn't checked if the new commit fixes my problems, but when setting up Devise today I was facing config.assets.initialize_on_precompile for heroku too - perhaps this is of interest for you:
  4. If you are deploying Rails 3.1 on Heroku, you may want to set:

   config.assets.initialize_on_precompile = false

 On config/application.rb forcing your application to not access the DB
 or load models when precompiling your assets.

Yeah, I added that to the README a few minutes ago.

Related: https://github.com/thomas-mcdonald/bootstrap-sass/pull/4

works for me - current head (cf3d74a83526) w/ config.assets.initialize_on_precompile = false. Although I was using sass-rails already, I guess the assets config did the trick.
btw, do you have a release plan / roadmap / sth like that where I can keep myself posted about the state of the project? rails_admin is really promising!

@5v3n There is a lot of styling to be done (on TB), some Javascript (filters, URI with AJAX requests in index view), AR factorisation (to pave the way for Mongoid), documentation (WIKI: one entry by field type, put #links in README for browsing, etc.).
Another thing is to open RA to the rest of the world. Tested and maintained extensions hooks would be cool.
I have some ideas about that I'd like to share when I have some time.
There is also some more heavy duty stuff with the conf engine.
If you are interested to work on smtg, open a ticket first, I'll help as much as I can!


Handle 0-dim tensors in cast_to_python_objects

Fix #5229

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


request: parse files inside tar.gz archives

That's the standard unix archive format, sometimes uses tgz extension but tar can be used with other compression formats for ex tar.xz

It's relatively easy to do.  Will consider.

@pseudotensor I can take a look at this. Could you please give me more context?

@Mathanraj-Sharma Sure, zip and gz/gzip are handled here: https://github.com/h2oai/h2ogpt/blob/9629901696f5d61c21ea92d45fa75638c0fc5817/src/gpt_langchain.py#L2298-L2346
.tar.gz or .tgz would be most similar to .zip, just use same package used for gzip to ungzip and then unpack the tar using some other package into a folder like the zip case.  Then otherwise very much like the .zip case where it recurses on the path created.


Check unused dependencies

I have a feeling that we have a list of dependencies that we don't need  eg ipfs

#439


[HOLD for payment 2024-06-20] [HOLD for payment 2024-06-18] [$250] Compose box - Browser's back arrow do not focus composer if first image preview open

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 1.4.74-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Issue reported by: Applause - Internal Team
Action Performed:
Precondition: upload multiple images in chat

Open the first uploaded image
Click the "Back" button in the browser

Expected Result:
Composer gets focused
Actual Result:
Last uploaded image preview opened
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/fb43f2cf-5fee-4545-8f25-4066cce2a725
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~013929a859819a7038
Upwork Job ID:<PHONE_NUMBER>114130945
Last Price Increase: 2024-05-27
Automatic offers:

DylanDylann | Contributor | 0
tsa321 | Contributor | 102496699

Issue OwnerCurrent Issue Owner: @jliexpensify

Can repro, adding External and probably fits into VSB best?

Proposal
Please re-state the problem that we are trying to solve in this issue
Browser back button open other images when user opens first attachment image in attachment view (and won't close attachment view) and press the back button.
What is the root cause of the problem?
In here:
https://github.com/Expensify/App/blob/e8ae3c5acedf0e6788dc574c7b6f3043ca37092a/src/libs/Navigation/AppNavigator/AuthScreens.tsx#L152-L157
When back button is pressed, the modal will close but not completely hidden yet. The code above will set modal visibility to false too early and will make:
https://github.com/Expensify/App/blob/e8ae3c5acedf0e6788dc574c7b6f3043ca37092a/src/pages/home/report/ReportActionCompose/ComposerWithSuggestions/ComposerWithSuggestions.tsx#L283-L284
shouldAutoFocus to be true. This will make RNMarkdownTextInput:
https://github.com/Expensify/App/blob/e8ae3c5acedf0e6788dc574c7b6f3043ca37092a/src/components/Composer/index.tsx#L324
autofocus to be true.
This will make composer immediately focused even though the modal is not completelly hidden(because there is some animation). The trap focuse in react native modal will detect if focus is outside modal and will make focus back to element inside the modal, and here will eventually make the image changes to other/ next images.
More context is in here:
https://github.com/Expensify/App/issues/27237#issuecomment-1746060535
and here : https://github.com/Expensify/App/issues/27237#issuecomment-1751632831
What changes do you think we should make in order to solve the problem?
In here we should add a condition:
https://github.com/Expensify/App/blob/e8ae3c5acedf0e6788dc574c7b6f3043ca37092a/src/libs/Navigation/AppNavigator/AuthScreens.tsx#L155-L156
we should add a condition, the code could be:
if (Modal.areAllModalsHidden()) {
    Modal.setModalVisibility(false);
    Modal.willAlertModalBecomeVisible(false);
}

This will check whether all modals is hidden completely.
Then the set of setModalVisibility and willAlertModalBecomeVisible are already exist in BaseModal - hideModal:
https://github.com/Expensify/App/blob/e8ae3c5acedf0e6788dc574c7b6f3043ca37092a/src/components/Modal/BaseModal.tsx#L76
we could use it.
This already fixed this issue.

To solve the closed issue that reappears above, in baseModal, we could call hide modal only in here:
https://github.com/Expensify/App/blob/e8ae3c5acedf0e6788dc574c7b6f3043ca37092a/src/components/Modal/BaseModal.tsx#L244
so we add hideModal inside handleDismissModal then remove onModalHide and onDismiss property of ReactNativeModal. This is because many types of modal (whether the modal support onModalHide or not) used in the app and put the hideModal call in here will make sure the hideModal is executed once.

Proposal
Please re-state the problem that we are trying to solve in this issue.
When an image attachment is opened inside a chat, pressing the browser back button will result in another image displaying, rather than being navigated back to the chat.
What is the root cause of that problem?
Inside the AttachmentCarousel component, the updatePage function is unexpectedly being called when the browser back button is pressed (due to how onViewableItemsChanged on FlatList). This causes onNavigate to be called with the first attachment in the viewable items, which then navigates the user to a different attachment.
What changes do you think we should make in order to solve the problem?
We should detect when the back button is pressed (potentially using a ref) and then return early inside the updatePage function. This will ensure that we're not unnecessarily fetching a different image and navigating the user to it. It will allow the user to go back to the chat

What alternative solutions did you explore? (Optional)
I looked into updating how modals are dismissed and shown, but realized that it would be more efficient to solve this through the attachment carousel logic

Proposal
Please re-state the problem that we are trying to solve in this issue.
Compose box - Browser's back arrow do not focus composer if first image preview open
This issue is reproducible for video attachments as well.
What is the root cause of that problem?
In FlatList component of AttachmentCarousel, onViewableItemsChanged is called when pressing browser back button without user interection.
What changes do you think we should make in order to solve the problem?
We should add waitForInteraction: true in viewabilityConfig
What alternative solutions did you explore? (Optional)

I can take over this issue as C+

All yours @DylanDylann!

@tsa321 Could you detail this point? Which logic does that?

The trap focuse in react native modal will detect if focus is outside modal and will make focus back to element inside the modal, and here will eventually make the image changes to other/ next images.

@arjun-dureja Could you deep dive into this point and explain why the updatePage is called? Is there any reference, document that explain why onViewableItemsChanged is triggered?

due to how onViewableItemsChanged works on FlatList

@CleverWolf1220 Why waitForInteraction will resolve this problem?

@DylanDylann  Focus event catch by react native modal ModalFocusTrap  is in here:
https://github.com/necolas/react-native-web/blob/54c14d64dabd175e8055e1dc92e9196c821f9b7d/packages/react-native-web/src/exports/Modal/ModalFocusTrap.js#L137
The function of this file based on the comment is to trap focus so the focus won't leave modal, if the focus is outside of modal, the trap focus will focus last element inside modal.
The code flow is:  Composer focused (from autofocus of RNMarkdownTextInput)-> focus event triggered -> catch by trapFocus (which will try to focus child or last descendant  element of the modal -> trap focus looping through descendant element -> until last element of the image list reached -> try to to focus the element of the attachment list -> then will cause onViewableItemsChanged will be fired because of the focus of the trapFocus attempt and make viewable image change to last rendered (initialNumToRender is 3 so the third attachment)-> will execute the handler in:
https://github.com/Expensify/App/blob/8375abea3a377e7416404addde255b6ac8530a9b/src/pages/home/report/ReportAttachments.tsx#L21-L25
Then navigate back to the modal attachment.

Hi Melv, thanks for tagging me. I will complete my review today

@DylanDylann

@CleverWolf1220 Why waitForInteraction will resolve this problem?

Sorry for late response. I found that my proposal solves this issue but causes other problems.

@tsa321's proposal looks good to me. Let's go with them
🎀 👀 🎀 C+ reviewed

@DylanDylann there wasn't a regression, right?

Yeah I think https://github.com/Expensify/App/issues/43222 unfortunately. I think we reverted this PR and @tsa321 is working on an updated fix here (let me know if that's right @DylanDylann and @tsa321)

@dangrous yes, my previous PR caused a regression. But after in latest main after bumping the latest version of react-native-live-markdown the regression issue and this issue are fixed.
But I notice this issue is also happens in edit message compose box. So in my newer  PR, I am reverting my previous PR and fixing this same issue on edit compose box.

Thanks for confirming everyone - so given that this is a regression, but also isn't (?), how should we handle payments here? Is it $125, or are we keeping at $250?

seems sorta weird that react-native-live-markdown would have fixed this - and the regression - though, right? Is there some other root cause? @DylanDylann and @tsa321 let me know what you think.
Not sure about payment, if we're able to still use this to fix a bug I think maybe it's fine?

@tsa321 Could you detail the problem mentioned in the new PR? (please attach a video for new bugs)

@DylanDylann same issue as this issue but in edit composer box
https://github.com/Expensify/App/assets/114975543/0352851b-e0f7-47f3-9e4b-11227cb2a1dc

@jliexpensify Let's remove the awaiting payment label. The PR is in the reviewing stage

@dangrous The original issue still reproduces in other places. Give me a bit of time to deep dive into the new PR

@tsa321 I can't reproduce your bug
https://github.com/Expensify/App/assets/141406735/cf1726e9-79ce-40cb-af8f-dfcdb146f903

@DylanDylann you are right. I think the behavior has changes, maybe after FocusTrap implemented. Should I close my PR?

@DylanDylann removed, does this mean that I'm not paying on the 20th? If so, will remove that from the title as well.

Summary: we have worked on this issue for a long time. After the original PR was merged, It caused a regression then we reverted the PR. Fortunately, while creating a new PR, we discovered that this issue was fixed by the new FocusTrap implementation.

@jliexpensify @dangrous  I am unsure how we handle the compensation for this case. Maybe half of the compensation might be a decent solution

Thanks for the summary. Hmm yeah, this is interesting - a regression would usually mean half the standard payout, which would be $125. But the solution wasn't actually used in the end.
I feel like we shouldn't compensate since another PR fixed the issue, but honestly I'm fine with $125 for each of you since there was some work involved. @dangrous , thoughts?

So given that another PR fixed the issue, I think typically in case we don't move forward with payment. But would love to work with y'all on future issues!

Thanks Daniel. I've cancelled the contracts and removed the job.


Compliance with ISO Rice document: Preface handling

The ISO preface clause should only be numbered (with 0, 0.1, 0.2...) IFF it has subsections.
DOC:

Rice:

The Word output is consistent with the sectioning rule; the difference is in markup, and mn-samples-iso does not mark up the Patent Notice any more. (I had originally done so in pursuit of semantic markup.) So this is a non-issue.


Apply linting rules with beautify-rewrite

This PR fixes linting errors.
@d3viant0ne pointed out at the bottom of #147 that the PR had introduced linting errors into the repo. I missed those last night, and wanted to fix my error(s).
This commit created by running:
$ ./node_modules/.bin/beautify-rewrite *.js

The results can be verified with:
$ npm run pretest

beautify-rewrite maintains the order of the meta-data comments vis-a-vis parameters, and a new branch on the MVE seems to work fine, but I'd love a double-check.
Thanks again to @goldhand, @MikaAK and @d3viant0ne for the rapid review and quick fix of these issues.

@jambonrose - Thanks for the pull request but I'm closing this in favor of #150 and a PR coming from @MikaAK which will strengthen our eslint rules significantly.
With the way Karma works with it's dependency injection, jsbeautify just isn't a viable option.

@d3viant0ne - Thanks for looking this over!
Sounds like my work here was invalidating my PR from yesterday! 😆


Using PageFactory with Appium is failing because DotNetSeleniumExtras.dll cannot be found

Description
I'm trying to use Selenium's PageFactory with AppiumPageObjectMemberDecorator. However, i receive errors when trying to load DotNetSeleniumExtras.dll.
Environment

.NET Core v2.1
Appium 1.9.0
Appium.Net v<IP_ADDRESS> beta

Details
In my code there is a copy of PageFactory object. I init objects with this PageFactory and AppiumPageObjectMemberDecorator(). After calling PageFactory.InitElements() with the decorator all the properties are populated by proxies as expected. However, when i try to access elements of the page i receive an error that DotNetSeleniumExtras.dll cannot be loaded from folder, even tho it is present next to my program's root dll (a.k.a the dll i am running).
I did some investigating (because i'm dev-friendly :D) and i found the error occurs in ByFactory.cs when it called Assembly.LoadFrom("DotNetSeleniumExtras.dll"). It seems i need a better way to control searching the DLL.
Code To Reproduce Issue [ Good To Have ]
Code in runner:
			LoginPage loginPage = PageFactory.InitElements<LoginPage>(driver);
			loginPage.Login(name, password);

Code in LoginPage:
	class LoginPage
	{
		[FindsBy(How = How.Id, Using = "name")]
		private IWebElement nameElement;

		[FindsBy(How = How.Id, Using = "password")]
		private IWebElement passwordElement;

		[FindsBy(How = How.Id, Using = "login")]
		private IWebElement loginElement;

		public bool Displayed => loginElement.Displayed;

		public void TypeName(String name)
		{
			nameElement.SendKeys(name);
		}

		public LoginPage(IWebDriver driver) { }

		public void TypePassword(String password)
		{
			passwordElement.SendKeys(password);
		}

		public void ClickLogin()
		{
			loginElement.Click();
		}

		public void Login(String name, String password)
		{
			TypeName(name);
			TypePassword(password);
			ClickLogin();
		}

Exception stacktraces
System.IO.FileNotFoundException: Could not load file or assembly '\SeleniumExtras.PageObjects.dll'. The system cannot find the file specified.
File name: '\SeleniumExtras.PageObjects.dll'
at System.Runtime.Loader.AssemblyLoadContext.LoadFromPath(IntPtr ptrNativeAssemblyLoadContext, String ilPath, String niPath, ObjectHandleOnStack retAssembly)
at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath(String assemblyPath)
at System.Reflection.Assembly.LoadFrom(String assemblyFile)
at OpenQA.Selenium.Appium.PageObjects.ByFactory.From(FindsByAttribute attribute)
at OpenQA.Selenium.Appium.PageObjects.ByFactory.CreateDefaultLocatorList(MemberInfo member)
at OpenQA.Selenium.Appium.PageObjects.ByFactory.CreateBys(ISearchContext context, MemberInfo member)
at OpenQA.Selenium.Appium.PageObjects.AppiumPageObjectMemberDecorator.Decorate(MemberInfo member, IElementLocator locator)
at TestProject.SDK.PageObjects.PageFactory.InitElements(Object page, IElementLocator locator, IPageObjectMemberDecorator decorator)
at
If you need any more information please let me know

Have you tried using
private void SetCurrentDirectoryToTestDirectory()
{
  var testDirectory = TestContext.CurrentContext.TestDirectory;
  Environment.CurrentDirectory = testDirectory;
  Directory.SetCurrentDirectory(testDirectory);
}

in a setup class of your unit testing framework?


Meteor compatibility

Hi,
would you know how to integrate your pacakge with Meteor? I tried this:
render() {
        var Toggle = Npm.require('react-toggle');

        return (

LOGO

                <Toggle
                    defaultChecked="true" />

        );

and this is breaking my other components. I did the npm install step.
Thanks for your help!

@iboxgithub it works with Meteor just fine, I'm currently using it with Meteor 1.3.
Instead of loading it with var Toggle = Npm.require('react-toggle'); you need to import it at the top of the file like so
import Toggle from 'react-toggle'

render() {
        return (

LOGO

                <Toggle
                    defaultChecked="true" />

        );


baresip overrides empty contacts file

If I make contacts file empty and start baresip, my empty contacts file is replaced by the default contacts file.  In my opinion, default file should be generated only if contacts file does not exist at all.  Any other opinions?

this logic is done by this function:
bool conf_fileexist(const char *path)
{
        struct stat st;

        if (!path)
                 return false;

        if (stat(path, &st) < 0)
                 return false;

        if ((st.st_mode & S_IFMT) != S_IFREG)
                 return false;

        return st.st_size > 0;
}

it checks if the size is > 0.
if you add an empty comment to the file, it will not be re-generated:
~/.baresip/contacts:
# empty

Alfred E. Heggestad writes:

it checks if the size is > 0.
if you add an empty comment to the file, it will not be re-generated:
~/.baresip/contacts:
# empty

Yes, I figured that out.  But why the size test?  Empty contacts file is
a valid contacts file.
-- Juha

there is no specific reason for the size test, I think.
I dont have any strong opinions about this.

I propose replacing
return st.st_size > 0;
with
return true.

the sounds good.
would you please be so kind to create a PR for that change ?
also please test that it does not have any strange side-effects :)
Alfred

Alfred E. Heggestad writes:

would you please be so kind to create a PR for that change ?
also please test that it does not have any strange side-effects :)

Done, Juha

Closed by commit
https://github.com/alfredh/baresip/commit/2fd98cd6977b0beae8cf98d25e344ced9bc93af4


gmaps4rails improvements - as per our email conversation

ben - as per our email conversations...  here is the list of things i changed/added:
•Made map initialization conditional on window.load to work around the IE "unspecified error", apparently caused by trying to initialize the map before the window and all the elements are loaded into the browser
•Added options to provide map id and map container id: <%= gmaps4rails_map(@json, { "processing" => ‘json’, "map_container_id" => "connections_map_container", "map_id" => "connections_map"}) %>
•Added option to provide "title" attribute to markers
•Added JS function "clear markers" to clear the map, needed by "replace markers" function
•Added JS function "replace_markers" to add new markers to the map. This is particularly useful for when you use AJAX to update your map without needing to re-initialize the map: Gmaps4Rails.replace_markers(your_markers_json_string)
Cheers

Should we be calling the function Gmaps4Rails.replace_markers(your_markers_json_string) or handler.replace_markers(your_markers_json_string) ?

Use the former if you have 1.x, the latter if you have 2.x

On 12 Jan 2017, at 05:17, gemmae<EMAIL_ADDRESS>wrote:
Should we be calling the function Gmaps4Rails.replace_markers(your_markers_json_string) or handler.replace_markers(your_markers_json_string) ?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.


Can't open a page that starts with http

Can't open a page that starts with http。

Can you give me an example?

Maybe it didn't work before, but as of right now loading sites such as http://www.alibaba.com/ works perfectly. So I'm going to close this issue. If you are still having problems, feel free to reopen this issue and let me know


Merge 'next' into 'main'

this times it's essentially a README upgrade.

Oh, and setup is depreacted now.


[Suggestion] Add Scoop installation instructions to Downloads page and Installation doc.

Hey @moudey
Do you know about a package manager for Windows 10 & 11 called Scoop?
It's a command line application that allows users to install a wide variety of programs into their system.
Anyway, Scoop has an app manifest for Nilesoft Shell that allows users of Scoop to install Nilesoft Shell from your website.
You can see right here for yourself: https://scoop.sh/#/apps?q=nilesoft+shell&s=2&d=1&o=true
Scoop installation instructions:
scoop bucket add extras

scoop install nilesoft-shell

Hi @Zliced13, Thank you for this contribution, I will include this command on download and docs page.


Can O' Spam: Watch sepaxml.com

Can O' Spam requests the watch of the watch_keyword sepaxml\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

sepaxml\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Makyen in Charcoal HQ


Fix HA behavior

We need to catch the events.HA_INFO_SLAVE_INITIALIZED event as well. This is observed when a node transitions to slave.
Finally closes #10 :)

Rebased my branch on top of the new master. This PR now also includes:

fixes suggested by pylint,
logger for unhandled exceptions raised in the background work function.


Global Alert Firehose

to: @chunyong-lin
cc: @airbnb/streamalert-maintainers
size: medium
follow up: #457
Background
The Firehose to deliver alerts to S3 should not be cluster based, it should be global.  See the tagged PR above for more context.
Changes

Introduce a new tf_stream_alert_globals module to house global configuration sets.  The idea with this module is to be a placeholder for any other global resources we'll need in the future.  We can eventually move resources into it as well.
Update the CLI to allow for adding new aws-firehose outputs.

Testing
Deployed and verified end-to-end in testing account

Coverage remained the same at 95.636% when pulling 1ec9881dad73529e37d753bd12cf34600b6c7d3a on jacknaglieri-global-alert-firehose into 2839cabc4370765837849a91ec06557defad142c on master.

@chunyong-lin we are moving towards using yapf to format all files in the repo, those changes were not made by hand.

Coverage remained the same at 95.636% when pulling df1d9c7bfa256933dabfe911ad715e06c714910a on jacknaglieri-global-alert-firehose into 2839cabc4370765837849a91ec06557defad142c on master.


doc/tutorial/basics: Correct description of comments

As discussed in https://github.com/cuelang/cue/discussions/858, "C-style comments" can be misleading, since the original comment syntax in the C language were multiline-capable /* comments */, which CUE does not support. I think describing these as "single-line comments" works well as a correction, since the reader is then drawn to inspect the code samples to observe the // syntax.

@NReilingh - I totally messed up this PR.  Hence my merge of this PR actually broke replication from Gerrit.
I will resubmit your change as a Gerrit CL later.


chore(project): make project easier to contribute to

By swapping ghooks for husky, adding a CONTRIBUTING.md and
adding the all-contributors table.
Adding existing committers to the all-contributors table:
@kentcdodds, @remy, @cmalard, @markdalgleish, @ryan-kimber, @jcollado,
@jamischarles, @erquhart, @tusharmath, @bitjson, @hisabimbola, @bahmutov,
@ds82, @mattlewis92, @tlvince, @adjohnson916, @zetlen, @opatut, @bmds,
@Emmurillo, and @Starefossen
Thanks everyone!
ref #53

Current coverage is 100% (diff: 100%)

Merging #54 into master will not change coverage

@@           master   #54   diff @@
===================================
  Files           1     1
  Lines          90    90
  Methods         0     0
  Messages        0     0
  Branches        0     0
===================================
  Hits           90    90
  Misses          0     0
  Partials        0     0

Powered by Codecov. Last update 12317ca...dbc6c64


Added L6 Th+ SST

Fixes #1100

Need to refresh PR import to bring in TH (not sure why its not there now).

@dosumis will not merge until you approve - thanks


Source Maps don't work on Chrome

Hello everyone,
I just started to use webpack and I'm having serious issues in debugging my code.
The problem is that the Chrome debugger doesn't work properly.
I'm not sure if this is a webpack issue, a Chrome issue or my fault.
This is my webpack file

var webpack = require('webpack');

module.exports = {
  entry: [
    './app',
  ],
  output: {
    path: __dirname + '/assets',
    publicPath: '/assets',
    filename: 'app.js',
  },
  devServer: {
    contentBase: __dirname + '/assets',
    host: '<IP_ADDRESS>',
    port: process.env.PORT,
    historyApiFallback: true,
    watchOptions: {
      aggregateTimeout: 300,
      poll: 1000,
    }
  },
  cache: true,
  devtool: 'inline-source-map',
  plugins: [
    new webpack.HotModuleReplacementPlugin(),
    new webpack.DefinePlugin({
      'process.env.NODE_ENV': '"development"',
    }),
  ],
  module: {
    preLoaders: [
    ],
    loaders: [
      {
        test: /\.js$/,
        include: [ __dirname ],
        exclude: /node_modules/,
        loader: 'babel-loader',
      },
    ],
  },
  node: {
    fs: 'empty',
  },
};

By changing the devtool option I get different behaviours:

eval: the debugger works correctly but the code is really hard to debug because I see the transpiled code
source-map: When I set a brekpoint in a certain line, chrome often moves that breakpoint in another line. When I use the step over functionality, chrome shows me the wrong line even though the line where I stopped the execution was correct  (usually the debugger moves the execution indicator where the function is declared)
hidden-source-map: same as eval
inline-source-map: same as source-map
eval-source-map:  The debugger adds the breakpoints on the correct line, but the execution never stops. This seems to be connected to #740
cheap-source-map: same as eval
cheap-module-source-map: same as source-map

I've tried to search both Chrome and Webpack related issues, changing browser or anything else it comes in my mind without success.

Having this same issue. Could also be related to Babel 6.

+1

I'm having this issue too. The interesting thing is that it only happens in Windows. In OS X and Linux the source maps line up correctly. Maybe there is some kind of LF/CRLF issue?
I verified that my source maps generated in windows, linux, and OS X line up correctly using this tool: http://sokra.github.io/source-map-visualization/

+1

@iknowcss I am also using my project in Windows, maybe this shows something.

I have this issue on OSX.
Also, https://phabricator.babeljs.io/T6842

Yes I have the issue on OSX too.

+1
Just tested a bunch of eval-* options in FF 45 and it works fine. Seeing the same problems as @bolismauro in chrome.
Tested on Chrome48  OSX10.10.5

+1 have this issue on OSX

I'm also having major problems with eval sourcemaps in Chrome 49 on OS X. Sourcemaps appear to work fine in Firefox 44.

+1 OSX

+1 on Windows Chrome 49.0.2623.8.
using devtool: source-map works for the time being, although much slower for dev.

FWIW if I set debug: true the sourcemaps work.

Seeing this now also. OSX, Chrome 49.0.2623.110.
Swapping to inline-source-map, again at the cost of dev time.
Out of interest, I've seen stack traces on other projects include line numbers from source maps (rather than app.bundle.js:100000:15). Is this something on the source-map side, or a browser add-in?

I'm seeing this as well on OS X 14.5.0 using Chrome 50.0.2661.75 (64-bit)

Haven't tested all of these options, but running into some of the same issues right now on Windows. 'inline-source-map' allows breakpoints to be hit in Chrome, but 'eval-source-map' doesn't... the breakpoints are never hit. Will do further testing with other options as I get time.

I'm on OSX, chrome (dev channel) refuses to load my maps. (console message)
I've created a gist
Here is a repo showing it:
https://github.com/jsg2021/broken-source-maps

In my broken-source-maps repo, I believe that I've isolated webpack as the sourcemap problem...

same here on Windows.
I have done few more testing. source-maps works until and unless they are not minified. When I try to minify by running web pack with -p or using the uglify plugin, I can not set break points at certain line. Its seems there is a mismatch between indexs

My guess: as a result of code modification and HMR, the JS running in browser changed, but in meanwhile, chrome doesn't update the sourcemap, so real code and sourcemap are not in-sync anymore, which results in breakpoints' malfunction. Possible?

+1 OSX

It's the size! Once the source maps get too large chrome is choking. I setup my project to split the node_modules from my own code and the vender chunk still dies, but my chunk's map works! :)

Seeing this happen on two Windows machines, but not on OS X (weird).

+1 OS X

There certainly seems to be a problem with Chrome 51. See Chrome Bug 611328.

"#inline-source-map" or "#source-map" made the breakpoint work on OSX Chrome, build/rebuild speed is slower though.

It's fixed (and confirmed working for me) in Canary now https://bugs.chromium.org/p/chromium/issues/detail?id=611328#c21

+1 osx

Just faced with the same one, fixed by set devtoolModuleFilenameTemplate: '[absolute-resource-path]' to the output section in config.
osx

+1 Windows

If you are not using canary, use @xuefengwang's suggestion and change source-map to inline-source-map in your webpack config.

Had the same issue , fixed by changing  source-map to inline-source-map  as suggested by @xuefengwang

I'm still seeing the issue in Canary 53.0.2777.0 on OS X. Changing devtool: '#eval-source-map' to devtool: '#inline-source-map' fixes it for me. So it doesn't look fixed.

for me, #inline-source-map is also not work.I finaly use    devtool: "inline-eval-cheap-source-map",.
and it's work.

devtool: '#inline-source-map' allows me to stop on the breakpoint; however it throws an error while trying to evaluate any variable in devtools' console.

+1 OSX

I had the same issue.
It was run build.js through node-static (https://www.npmjs.com/package/node-static)
Then I run my build js file through apache server and got working sourcemaps.

inline-source-map fixed it on OSX for me. This is a chrome issue though.

Using:

<EMAIL_ADDRESS>devtool: 'inline-source-map'

Got:

Hash: 4d14bfc9f2b8f52d9e41
Version: webpack 2.1.0-beta.17
Time: 4838ms
Asset    Size  Chunks             Chunk Names
bundle.js  366 kB       0  [emitted]  main
chunk    {0} bundle.js (main) 1.06 MB [entry] [rendered]

Using:

devtool: 'inline-eval-source-map'

Got:

Hash: 1c7303437b00d5447c7a
Version: webpack 2.1.0-beta.17
Time: 3574ms
Asset     Size  Chunks             Chunk Names
bundle.js  2.88 MB       0  [emitted]  main
chunk    {0} bundle.js (main) 1.06 MB [entry] [rendered]

Using inline-source-map or source-map with(out) # is not detected by webpack as valid devtool value (sad thing is that doesn't report anything about bad configuration).
Actually I don't know how I can inyect sourcemaps for debugging purpose.

This is still broken.  Any update?  I don't think it is just chrome... GetSentry can't seem to parse non-inline source-maps for production debugging purposes

I was able to fix the issue that setting breakpoints in Chrome's console did not work when using eval-cheap-module-source-map by defining devtoolModuleFilenameTemplate as suggested by @andrii-frankiv in https://github.com/webpack/webpack/issues/2145#issuecomment-225906074. Thanks!

devtool: '#inline-source-map' fixes it for me...
See another issue too.. "this" context is incorrectly showing up as being set to window instead of its current context.
Can even 'console.log(this)' before a debugger statement and the context is correct, however once debugger fires, typing "this" in the console returns window.
Anyone have any ideas?

@buildbreakdo because in the transpiled code the context is probably mapped to a different variable, such as _this or _this6 (depends on the code structure). In the console you're evaluating the transpiled code, not the original source.

@elado Thanks! Suspicion was along those lines.. sometimes "this" is the correct context, sometimes not, assume a change is being made but I'm not sure what it is.
As you suspected -- when "this" is set to the wrong context -- "_this" is the expected context. Is there any reliable way to avoid this behavior (doesn't always happen, so strange)?
Thanks again!

@buildbreakdo I don't think the console uses the sourcemaps to map variables. You can disable devtool and see the actual source, or use the Scope pane (on the right of the debugger) while debugging to see the available variables.

@elado Looks like something landed recently but you need to be using Chrome Canary, see here (scroll to bottom):  https://bugs.chromium.org/p/chromium/issues/detail?id=327092
Actual commit here:
https://codereview.chromium.org/1770263002/diff/20001/third_party/WebKit/Source/devtools/front_end/sources/SourceMapNamesResolver.js

Had same problem with my source map either working or being not correct line wise. But using:
new webpack.SourceMapDevToolPlugin({
			filename: '[file].map'
		})

have solved my problems instead of using devtool: 'source-map'. Just a heads up if someone lands the same issues.

I'm having the same issue on both firefox and chrome, it seems the modules are missaligned

@aventic I still get the same problem with your change. It looks like a Chrome bug because the inline and the external source maps are the same JSON.

can confirm that this is a bug in Chrome, it's fixed in Version 54.0.2817.0 (64-bit)

@andrii-frankiv that doesn't fix anything

can confirm it's fixed in Version 54.0.2810.2 dev (64-bit)

and fixed in Version 52.0.2743.82 beta (64-bit) for me...

This issue should be closed out now that the fix has landed for the Chrome stable channel.

Can we confirm that any related Chrome Source map issues have this fixed?

Can we confirm that any related Chrome Source map issues have this fixed? For any of the devtool: options.

No. My comment still stands, both in Chrome 52 stable & Canary 54: https://github.com/webpack/webpack/issues/2145#issuecomment-228311436

There's actually two separate issues.
One is that non-inline, non-eval source maps didn't work in Chrome. That's since fixed in Chrome 52.
The other is that breakpoints on initial code execution don't work with eval source maps in at least Chrome and maybe other browsers. That one is still outstanding, but it's a different problem.

The issue reported with "eval" sourcemaps is https://bugs.chromium.org/p/chromium/issues/detail?id=459499, which is still open.
The issue reported with non-inline sourcemaps is https://bugs.chromium.org/p/chromium/issues/detail?id=611328, which is resolved.

Thank you very much. @taion would you be willing to create an issue to track these including this one. I can get around to it later if I need to.

Is there something in particular you're looking to track? I don't think there's anything webpack can do here. The issues are all upstream. Are you just looking for placeholders to track the matching Chromium issues?

Both. That way I can keep it organized. Completely up to you to do, just takes off one more thing on our to-do list to tackle.

Eval isn't supported by CSP default-src 'self' so why should it be supported by webpack?

Eval source maps just have some nice properties for development. You absolutely should not use them in production.
@TheLarkInn: I opened https://github.com/webpack/webpack/issues/2846. I don't think it makes sense to track the issue on Chrome with non-inline sourcemaps any more, given that the fix has already landed in the Chrome stable channel.

Eval source maps might have nice properties, but should browsers ever have supported inline or eval JavaScript?

Thank you very much all.

@taion I think the only question that remains is: Is there a separate chrome bug in regards to inline-source-map. They seem to exhibit the same behavior as source-map previously did before chome fixed it.

@TheLarkInn I haven't seen any bugs with inline source maps. What issue do you mean?

Works for me too
On 9 Aug 2016 5:08 pm, "Jimmy Jia"<EMAIL_ADDRESS>wrote:

@TheLarkInn https://github.com/TheLarkInn I haven't seen any bugs with
inline source maps. What issue do you mean?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/webpack/webpack/issues/2145#issuecomment-238602936,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZQTLEvGPrukQThZvQZURGqUqEV6jNeks5qeKXogaJpZM4HqOxx
.

I think there's a problem with eval source maps though
On 9 Aug 2016 5:08 pm, wrote:

Works for me too
On 9 Aug 2016 5:08 pm, "Jimmy Jia"<EMAIL_ADDRESS>wrote:

@TheLarkInn https://github.com/TheLarkInn I haven't seen any bugs with
inline source maps. What issue do you mean?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/webpack/webpack/issues/2145#issuecomment-238602936,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZQTLEvGPrukQThZvQZURGqUqEV6jNeks5qeKXogaJpZM4HqOxx
.

There is – I opened an issue for that on https://github.com/webpack/webpack/issues/2846 per earlier request.

I should add that I was able to fix my source map issues by:

Upgrading to Chrome 52
Reseting my Chrome DevTools
Restarting Chrome
Removing and re-mapping my local resources to network resources

I've tested with {devtool: 'inline-source-map'} and {devtool: 'eval-source-map'}.

I'm having this same issue in firefox

same issue with 'eval-source-map' in chrome 52.0.2743.116 m. And also chrome canary (54.0.2826.0 canary (64-bit))

Btw, since I'm stuck using 'cheap-module-source-map', I decided to do some profiling of webpack to see if there's anything that could be cached/changed to speed up the sourcemap generation on incremental builds. Here's one improvement I found:
var MappingsContext = require("source-list-map").MappingsContext;

/**
 * Note: this code was copied over from the original implementation and
 * modified to do lookups using a Map to get O(log(n)) performance instead of indexOf(), which is O(n)
 */
MappingsContext.prototype.ensureSource = function(source, originalSource) {
    this._sap_sourcesIdxMap = this._sap_sourcesIdxMap || new Map();
    var idx = this._sap_sourcesIdxMap.get(source);
    if(idx !== undefined) {
        return idx;
    }

    // old code follows:
    // originally lookup was done using indexOf
    // var idx = this.sources.indexOf(source);

    idx = this.sources.length;
    this.sources.push(source);
    this._sap_sourcesIdxMap.set(source, idx);
    this.sourcesContent.push(originalSource);
    if(typeof originalSource === "string")
        this.hasSourceContent = true;
    return idx;
};

The other time hog is the fromStringWithSourceMap() function, but I'm not exactly sure how to refactor it. The problem seems to be related to:

base64VLQ.decode()  - happening a lot, not sure why decoding is necessary to generate the sourcemaps
The lines of code being split into an array and then being put back together?
I've pasted the source code here in case somebody gets an idea:

var base64VLQ = require("./base64-vlq");
var SourceNode = require("./SourceNode");
var CodeNode = require("./CodeNode");
var SourceListMap = require("./SourceListMap");

module.exports = function fromStringWithSourceMap(code, map) {
	var sources = map.sources;
	var sourcesContent = map.sourcesContent;
	var mappings = map.mappings.split(";");
	var lines = code.split("\n");
	var nodes = [];
	var currentNode = null;
	var currentLine = 1;
	var currentSourceIdx = 0;
	var currentSourceNodeLine;
	mappings.forEach(function(mapping, idx) {
		var line = lines[idx];
		if(typeof line === 'undefined') return;
		if(idx !== lines.length - 1) line += "\n";
		if(!mapping)
			return addCode(line);
		mapping = { value: 0, rest: mapping };
		var lineAdded = false;
		while(mapping.rest)
			lineAdded = processMapping(mapping, line, lineAdded) || lineAdded;
		if(!lineAdded)
			addCode(line);
	});
	if(mappings.length < lines.length) {
		var idx = mappings.length;
		while(!lines[idx].trim() && idx < lines.length-1) {
			addCode(lines[idx] + "\n");
			idx++;
		}
		addCode(lines.slice(idx).join("\n"));
	}
	return new SourceListMap(nodes);
	function processMapping(mapping, line, ignore) {
		if(mapping.rest && mapping.rest[0] !== ",") {
			base64VLQ.decode(mapping.rest, mapping);
		}
		if(!mapping.rest)
			return false;
		if(mapping.rest[0] === ",") {
			mapping.rest = mapping.rest.substr(1);
			return false;
		}

		base64VLQ.decode(mapping.rest, mapping);
		var sourceIdx = mapping.value + currentSourceIdx;
		currentSourceIdx = sourceIdx;

		if(mapping.rest && mapping.rest[0] !== ",") {
			base64VLQ.decode(mapping.rest, mapping);
			var linePosition = mapping.value + currentLine;
			currentLine = linePosition;
		} else {
			var linePosition = currentLine;
		}

		if(mapping.rest && mapping.rest[0] === ",") {
			mapping.rest = mapping.rest.substr(1);
		}

		if(!ignore) {
			addSource(line, sources ? sources[sourceIdx] : null, sourcesContent ? sourcesContent[sourceIdx] : null, linePosition)
			return true;
		}
	}
	function addCode(generatedCode) {
		if(currentNode && currentNode instanceof CodeNode) {
			currentNode.addGeneratedCode(generatedCode);
		} else if(currentNode && currentNode instanceof SourceNode && !generatedCode.trim()) {
			currentNode.generatedCode += generatedCode;
			currentSourceNodeLine++;
		} else {
			currentNode = new CodeNode(generatedCode);
			nodes.push(currentNode);
		}
	}
	function addSource(generatedCode, source, originalSource, linePosition) {
		if(currentNode && currentNode instanceof SourceNode &&
			currentNode.source === source &&
			currentSourceNodeLine === linePosition
		) {
			currentNode.generatedCode += generatedCode;
			currentSourceNodeLine++;
		} else {
			currentNode = new SourceNode(generatedCode, source, originalSource, linePosition);
			currentSourceNodeLine = linePosition + 1;
			nodes.push(currentNode);
		}
	}
};

+1

I had this while I was using devtools='eval-source-map', and changing it to 'inline-source-map' solved this. I mean, the chrome debugger was not stopping at breakpoints, and after the fix it started stopping.

Also have this issue with webpack 2 latest.

I've been reading the comments and am using chrome 52. I've switched from inline-source-maps to source-maps but now chrome is giving me this each time:

I have an open bounty on the above issue on SO: http://stackoverflow.com/questions/39146381/sourcemaps-are-detected-in-chrome-but-original-source-is-not-loaded-using-webpa

Seems that the link to the babeljs issue posted previously is dead. Found the issue was moved to github here: https://github.com/babel/babel/issues/3887

Still a problem for me in Chrome 53.0.2785.92 and webpack 1.13.2 on Linux. Is anyone else getting this problem on Linux? Earlier comments said its working fine for them.

Also here on OSX and same Chrome as above, breakpoints are not breaking with eval-cheap-module-source-map. All works with source-map but of course with a much slower compilation.

cheap-module-eval-source-map broken here.  macOS 10.11.6, Chrome 53

Since I received negative feedbacks I clarify my +1: using cheap-module-eval-source-map in chrome 53 on macOS 10.11.5 and using webpack 1.13.2 I get the same js contents as @brianblakely:
undefined

/** WEBPACK FOOTER **
 **
 **/

I've found a solution. Use plugin new webpack.SourceMapDevToolPlugin() instead of devtool param (this param must be removed from configuration).

I can second @brianblakely and @matteoantoci's problems with cheap-module-eval-source-map.  I also tried @ruscoder's solution, which did work, but killed performance.  I set columns to false, to see if performance would improve, but I got the same problem as before, with the undefined in the map.

It also works replacing devtool: 'cheap-module-eval-source-map' by devtool: 'eval-source-map' (in webpack.config.development.js).
I guess it reduces the performances.

Thanks @ruscoder, using SourceMapDevToolPlugin made my day
  // devtool: 'cheap-module-eval-source-map',
  plugins: [
    new webpack.SourceMapDevToolPlugin(),
    ...
  ],

@ruscoder 's solution works, but build speed is almost half as fast.
You can adjust the options here:
https://webpack.github.io/docs/list-of-plugins.html#debugging
to get faster performance. The last 3 (module, columns, lineToLine) bring build speed back to where it was, but the line numbers are off. I think if you configure lineToLine and the top test, exclude, include options you should be able to reduce build speed.

devtool: '#inline-source-map' is working for me at least in Chrome Canary on Mac.

The problems seems related with "cheap" mode. I'd like to have a more performat setup in dev but at the moment I'm using this configuration:
const DEVTOOL = DEBUG ? '#eval-source-map' : '#source-map';

If you set the columns option to false, on the SourceMapDevToolPlugin it behaves the same way as using any "cheap" mode devtool.

Sorry is this resolved or is there some accepted workaround? I cannot get breakpoints to work AT ALL on (host is Mac OS X El Capitan v10.11.6):

Chrome Canary Version 56.0.2895.0 canary (64-bit)
Safari Technology Preview Release 15 (Safari 10.1, WebKit 11603.1.8)
Firefox Developer Edition 51.0a2(2016-10-19)(64-bit)

I don't really ever use the latter 2 but I downloaded and tried them for completeness sake.
My dev environment is located on a Vagrant box running Ubuntu-16.04, the site itself is served through apache, but I launch a separate process for webpack-dev-server with:
webpack-dashboard -- webpack-dev-server -d --inline
I then have all the necessary scripts loaded on my page using the following script tags (as an example):
<script type="text/javascript" src="http://<IP_ADDRESS>:8000/assets/index.js"></script>
So the page auto-refreshes whenever any save any changes.
Anyway I see my original code ok, and stuff I send to the console actually gets tagged on from the correct line number, however, breakpoints refuse to work AT ALL. Things i've tried:

Every possible devtool (not joking), and truthfully I have no problem with long build times so if breakpoints worked I would not mind source-map at all
SourceMapDevToolPlugin still did not work.
Editing my .babelrc to the very barebones ES2015 preset, I found some saying this is a problem with babel.
Turning on sourcemaps from the babel config (both true and both) broke the whole system entirely.. but I was desperate.

Anyway, I'm still mostly starting out with this stuff so i'm almost sure i must be missing something, cause this would otherwise be a much more serious and common issue online otherwise.
I'm including my webpack.config.babel.js and .babelrc files just in case. Would appreciate ANY help or suggestions as this has really put a dent in my workflow.
//webpack config
import path from 'path';
import ManifestPlugin from 'webpack-manifest-plugin';
import CommonsChunkPlugin from 'webpack/lib/optimize/CommonsChunkPlugin';
import DashboardPlugin from 'webpack-dashboard/plugin';
import WriteFilePlugin from 'write-file-webpack-plugin';
import SourceMapDevToolPlugin from 'webpack/lib/SourceMapDevToolPlugin';

module.exports = {
    context: path.join(__dirname, 'Resources'),
    entry: {
        vendor: [
                    'jquery',
                    'moment',
                    'fastclick',
                    'nprogress',
                    'bootstrap-loader',
                    'jquery-flot',
                    'select2',
                    'select2/dist/css/select2.min.css',
                    'multiselect',
                    'multiselect/css/multi-select.css',
                    'icheck',
                    'bootstrap-daterangepicker',
                    'font-awesome-sass-loader',
                ],
        index: './Index',
        login: './Login',
        actionLog: './ActionLog',
    },
    output: {
        path: path.join(__dirname, 'assets'),
        filename: '[name].js',
        chunkFilename: '[name].js',
        publicPath: 'http://<IP_ADDRESS>:8000/assets/'
    },
    devtool: 'source-map',
    module: {
        loaders: [
           {
               test: /\.js$/,
               include: path.join(__dirname, 'Resources'),
               loader: 'babel-loader'
           },
           {
               test: /\.(png|woff|woff2|eot|ttf|svg|gif)$/,
               loader: 'url-loader?limit=8192'
           },
           {   test: /\.(ttf|eot|svg)(\?v=[0-9]\.[0-9]\.[0-9])?$/,
               loader: "file-loader"
           },
           {   test: /\.jpg$/,
               loader: ['file?name=[name].[ext]']
           },
           {
               test   : /\.css$/,
               loaders: ['style', 'css', 'resolve-url']
           },
           {
               test: /\.scss$/,
               loaders: ['style', 'css', 'resolve-url', 'sass?sourceMaps']
           },
           {
               test: require.resolve('jquery'),
               loaders: ['expose?$', 'expose?jQuery']
           },
           {
               test: require.resolve('nprogress'),
               loaders: ['expose?NProgress']
           },
           {
               test: require.resolve('moment'),
               loaders: ['expose?moment']
           },
           {
               test: require.resolve('fastclick'),
               loaders: ['expose?FastClick']
           },
           {
               test: require.resolve('skycons'),
               loaders: ['expose?Skycons']
           },
           {
               test: require.resolve('icheck'),
               loaders: ['expose?iCheck']
           },
           {   test: /bootstrap-sass\/assets\/javascripts\//,
               loader: 'imports?jQuery=jquery'
           },
       ]
    },
    devServer: {
        host: "<IP_ADDRESS>",
        port: 8000,
        stats: 'minimal',
        clientLogLevel: 'info',
        outputPath: path.join(__dirname, 'assets'),
        watchOptions: {
            aggregateTimeout: 300,
            poll: 1000
        }
    },
    plugins: [
        new ManifestPlugin(),
        new CommonsChunkPlugin({
            name: ['bootstrap'],
            minChunks: Infinity
        }),
        // new SourceMapDevToolPlugin({
        //     filename: '[file].map',
        //     exclude: ['vendor.js'],
        //     columns: false
        // }),
        new WriteFilePlugin({
            log: false
        }),
        new DashboardPlugin()
    ]
};

I'm in the process of updating a system which had mostly legacy JS code, which is the reason behind some of the includes and loaders, I also need the WriteFilePlugin as I use a PHP Templating engine Twig to insert my webpack entry points, and this requires the manifest.json file to be generated in my /assets/ directory on disk, twig has no access to the files webpack keeps on memory.

// .babelrc
{
  "presets": [
    "react",
    "es2015",
    "stage-0"
  ],
  "plugins": [
    "transform-runtime",
    "react-html-attrs",
    "transform-decorators-legacy",
    "transform-class-properties"
  ],
  "retainLines": true //just experimenting, only difference I saw from this is that the I could set breakpoints on the lines I wanted in the devtool, still would be completely ignored however.
}

I try to put a breakpoint on that console.log... but it gets completely ignored.
Anyway, I apologise for the ridiculously long post, I just wanted to be as thorough as possible to make sure I don't miss some key detail without knowing.

P.S. placing a debugger command in the file does what it's meant to, but stepping forward from there goes back to the webpack generated files, so  impossible to actually follow what's going on from there.

@Sijan117  it might be your version of webpack. I believe I am still on 1.13.0 or somethinglike that.Try to downgrade ... Also I would file a bug. With that level of detail it is sure to get attention from the webpack people... I dont think threads like these are on tjeir radar.

FYI, I think I have a half hacky solution to the problem, I wrote a plugin to produce indexed sourcemaps. Indexed sourcemaps allow you to regenerate only the sourcemap for a specific module. To generate the chunk sourcemap, all you need to do is calculate the offsets and put the cached module sourcemaps together. It's pretty fast for me and we have about 5000 modules.
see https://github.com/webpack/webpack/issues/3087

I can confirm the issue is still there with webpack 2.1.0-beta.25

If you're using hot module reload, adding the following before your dom is rendered works in conjunction with eval-source-map to fix hmr not reloading:
// https://www.garysieling.com/blog/3183-2
if (module && module.hot) {
  module.hot.accept()
}

Changing devtool setting from devtool: cheap-module-eval-source-map  to #inline-source-map works for me! Thanks to @tysonnero

source-map is working for me (breakpoints work, correct code shown) on Windows 7 Enterprise, webpack 1.12.
However, the performance hit on incremental builds is terrifying (up to 4 seconds from 0.5), so it does not really help.

@csvan Your solution worked for me, breakpoints work 100% as long as I do not hot reload, once I hot reload, they work 0%. Is this your case too?

source maps work OOTB, but not with hot reload. being that this was my first webpack/angular 2 app, was quite confusing spelunking down this thread.

@AlexKvazos we do not have hot reloads enabled, our project only uses incremental build-and-reload, so unfortunately I don't know about that specific case.

If you had issues with cheap-module-source-map, try updating to Webpack 1.14.0. It included https://github.com/webpack/source-list-map/pull/2 which fixed completely broken sourcemaps for me.

@gaearon are you implicitly saying using 2.1.0-beta.+ is a no go?
I think a lot of people here might be attempting to use the latest webpack.

Sorry, I should've been clear I'm referring particularly to Webpack 1.x.
I don't know where/when the corresponding fix for Webpack 2 would land.

@faceyspacey, the fix in webpack 1.14.0 is that it enforces<EMAIL_ADDRESS>(which contains the fix). If you remove your node_modules/ folder (and upgrade your yarn.lock / npm-shrinkwrap.json) and re-install your modules, you should also get<EMAIL_ADDRESS>

In webpack 2.1.0-beta changing devtool to eval-source-map fixed it for me. Thanks @csvan!

Because the update to source-map-list is a patch version, no change is needed for webpack2 users either.
The simplest way to upgrade with a yarn.lock file is to find the source-map-list line, delete it, then do a yarn --force. Double-check the yarn.lock to be sure you got 0.1.7 and you're good!

Just a note for others following along that the relevant package is named source-list-map, not source-map-list.

I upgraded to<EMAIL_ADDRESS>and I'm still having trouble placing breakpoints. Most of the time the breakpoints are incorrectly placed earlier in the code than where it visually indicates.

+1

Same as @fracmak, updating source-list-map still doesn't produce source maps accurately enough. eval-source-map works well, though.

Can you provide a minimal example and exact instructions to reproduce for where its results are bad?

@gaearon I can't. 😕 I've been trying by gradually reducing my configuration until the problem disappears, but it doesn't seem to disappear and re-appear consistently, I can't find a pattern. On a new project from scratch this issue doesn't happen, so I guess it's something very specific to my project's environment.
But yeah, that means that updating source-list-map should generally work fine.

So I put together the most simplistic example I could come up with.
https://github.com/fracmak/sourcemap-fail
It's basically React/ReactDOM with react-css-modules. If you comment out the react-css-modules in src/Test/index.js on line 2, you can now place a breakpoint on the console.log(). If you put in that import, the breakpoint is no longer accurate.

I tested all options with following setup:

win32
webpack-dev-server 2.2.0-rc.0
chrome 55.0.2883.87
source-list-map 0.1.7

The results are:

devtool = 'source-map'; // works
devtool = 'eval-source-map'; // fails
devtool = 'cheap-module-source-map'; // works but misses line numbers
devtool = 'cheap-module-eval-source-map'; // fails
devtool = 'cheap-source-map'; // works but not original ts and misses line numbers
devtool = 'cheap-eval-source-map'; // fails
devtool = 'eval'; // works but not original ts

sourcemapping are still incorrect in 2.2.0-rc.1
using cheap-module-source-map in this example:
in my editor

in Chrome 55

@mariussl could you show me your config files? Thanks!

@andrei-cacio : here we go.
162121_webpack_config.zip

+1
Using webpack 1.14.0 with babel and es2015 (imports).
Source maps don't work on Chrome with source-maps (lines are wrong).
They do work with inline (but very big file) and with eval (but files are not original).
Really would like a solution.

Upgraded to Webpack 1.14.0, cheap-module-source-map works, but cheap-module-eval-source-map doesn't.

Had same problem:
Chrome(v. 55.0.2883.95 ) on macOS Sierra(v. 10.12.1 )
Upgraded Webpack to 1.14.0 and it worked for cheap-module-eval-source-map

I have the same problem with you @mariussl

Chrome (v 55.0.2883.87 m) on windows., webpack 2.2.0-rc.3
devtool: "cheap-module-source-map" used to work just fine but doesn't anymore using to
plugins[  .... new webpack.SourceMapDevToolPlugin() ... ])
Worked perfectly

I can't debug the webpack-starter on Chrome 55.0.2883.87 m Windows 10 64 Bit with Webpack 2.2.0-rc.4

+1 OSX
I can't debug on Chrome lasted.
I try on Firefox can debug & breakpoint.

Using webpack 2.2.0 final release works great for me with devtool: '#source-maps',

i think people are looking for the cheap source maps to work

My source maps still aren't working even with the latest release:
webpack: 2.2.0
chrome: 55.0.2883.95
devtool: '#source-maps'
os: OSX
however, the seem to be working just fine with webpack 1.14.0

since webpack 2, the UglifyJsPlugin apparently has sourceMap: false by default so you need to explicitly set it to true in the config
https://gist.github.com/sokra/27b24881210b56bbaff7#gistcomment-1863573

While this bug is being fixed, in our project we settled with the following workaround:

Development config: transpile imports with BabelJs and use cheap-module-eval-source-map for fast debugging feedback cycles. When Babel resolves the imports, the cheap source maps are correct.
Production config: use source-map (for correct source maps on production bug reports) and do not transpile imports with BabelJs, so that we can get a smaller bundle with webpack's tree shaking.

During development we don't care about the bundle size, while for production we don't care about (incremental) compilation times, so these two combinations are acceptable until a fix is out.

Hi everyone kind enough to report in this thread, if you didn't know we have shipped webpack 2.2.1 to the latest tag on npm. I'd love if you could all test and report the following:
Does sourcemaps work correctly? If not, report the symptom:
Sourcemap type: (IE: devtool: "cheap-module-source-map")
Chrome version:
OS:
I have a new working group with some Chrome Developers looking to tackle and address this issue. So looking forward to get as much data as possible to verify this is still an issue or not. Thank you all so much.

@TheLarkInn I just tested sourcemap generation with 2.2.1 and it works well when setting the sourceMap: true for both source-map and cheap-module-source-map.

@alexnm what chrome version are you testing it on?

@andrei-cacio Version 55.0.2883.95 (64-bit)

I've updated my sample project to the latest dependencies and it's still causing the same issues:
https://github.com/fracmak/sourcemap-fail
Chrome: 56.0.2924.76
macOS: 10.12.3
When you run my project, you can't put a breakpoint on the console log in Test/index.js. But if you comment out the react-css-modules import you suddenly can.

@TheLarkInn - My Report..
Webpack 2.2.1, webpack-dev-server 2.3.0, Code - Typescript
Sourcemap - cheap-module-source-map
OS: Windows
Chrome: 56.0.2924.87
tsconfig to contain module:"es2015"
With above config - code stops on breakpoints but they do not match with the actual source line numbers.
I tried with SourceMapDevToolPlugin and it worked.. but bigger bundle.js file almost 10 times bigger as compared to cheap-module-source-map and hence became too slow for download.
I tried with inline-source-maps and it worked too. The bundle file took 50 seconds which is beyond acceptable for development.
Hope that will come handy

Has anyone found a fix for this?
simply doing devtool: 'source-map' does not work for me.

@anthonyettinger now devtool: '#source-maps' at https://github.com/webpack/webpack/issues/2145#issuecomment-274261381 @graingert great for me.

@tlecreate this doesn't seem to be working for me, although I see CSS maps in the source tree. I am using es2015, uglify and Chromium 55.

devtool: '#source-maps' not working for me. Other attempts failed as well

actually the problem is not related to sourcemaps at all, at least in my case:
I disabled devTool completely and the app.js bundle is still off by one line in devtool.
did any of you guys had the curiosity to disable devTool and check the lines?
my specs: OS X, no babel, no other loaders, just an app bundle with 65k lines (without vendor)

I was using SourceMapDevToolPlugin and was seeing issues with source map. Removed that plugin and just enabled inline-source-map and now source maps are working perfectly fine.

@TheLarkInn
I think that this issue still exists, in my case see gif below.

devtool: 'eval-source-map' // works
devtool: 'cheap-module-eval-source-map' // doesn't work correctly

Repository
https://github.com/hinok/webpack2-react-router-code-splitting
Reproductions steps
npm install # or yarn
npm start # or yarn start

# 1. Browser should open automatically with localhost:9000
# 2. Open DevTools
# 3. Click on link SourceMaps doesn't work at the top

OS: macOS Sierra 10.12.3
Chrome: 56.0.2924.87 (64-bit)
Node: v6.9.1

still an issue for me in terms of hitting breakpoints in chrome dev tools on page load specifically. i've tried cheap-module-source-map, source-map, inline-source-map, eval, and cheap-module-eval-source-map

After upgrading to Webpack 2.2.1 from 1.13, I find that source-map and inline-source-map seem to work as expected. The downside is that they take much longer to build than under 1.13 (where they did not work as expected anyway, so that is perhaps to be expected).
I have tried using the SourceMapDevToolPlugin directly, particularly because I want to exclude my vendors chunk from the mapping process. However, this again leads to source maps which do not work reliably at all.

By the way, what is the difference between #source-map and source-map, if any? I can see them used interchangeably in the docs, but there is no explanation anywhere regarding their relationship.

Prefixing @, # or #@ will enforce a pragma style. (Defaults to @ in webpack@1 and # in webpack@2; using # is recommended)

@csvan http://webpack.github.io/docs/configuration.html#devtool

@dickeylth thanks. I wonder if the default to # actually works as the docs state. It may be a project glitch, but I can confirm that using #source-map breaks our build (the resulting .js files are corrupt and missing modules), whereas just using source-map does not.

Changing
{
    "sourceMaps": "both"
}

to
{
    "sourceMaps": true
}

in .babelrc fixed it for a project I'm working on (express server + webpack-dev-middleware + react-hot-loader).

Note that there is a new known issue that affects any cheap sourcemaps on Webpack 2 when you use Webpack's native ES modules support: https://github.com/webpack/webpack/issues/4423. So if that affects you, you can try to compile modules with Babel in the meantime.

@gaearon What source maps should we use so that we can see updating code on hot reload?

I don't know. I think this worked with 'eval' at some point but that's not really a source map.

@gaearon I see, yeah, those are hard to read. What is the issue that is focused on nailing sourcemaps with hot reloading? I see many of them and they are focused towards different things (sourcemaps related but not hot reloading).

I don't know if one exists, sorry! We'll be keeping track of that in Create React App when we get closer to enabling hot reloading there.

I've encountered issues with debugging in Chrome recently as well.
Chrome: v56.0.2924.87
webpack: v2.2.1
With the following webpack config I can successfully debug app.bundle.js but not source code files such as component.js.
var webpack = require('webpack');

module.exports = {
  context: __dirname + '/src/assets/app',
  entry: {
    app: './app.module.js',
    vendor: ['angular']
  },
  output: {
    path: __dirname + '/src/assets/jsBundles',
    filename: 'app.bundle.js'
  },
  target: 'web',
  plugins: [
    new webpack.optimize.CommonsChunkPlugin({
      name: 'vendor',
      filename: 'vendor.bundle.js'
    }),
    new webpack.SourceMapDevToolPlugin({
      filename: '[file].map',
      exclude: ['vendor.bundle']
    })
  ],
  module: {
    rules: [
      {
        test: /\.html$/,
        use: ['html-loader']
      }
    ]
  }
};

My debugging process in Chrome is to: • Set a breakpoint at the top of the file • Reload the page • Make changes to the JS within the file • Resume script execution

With v2.2.1 I still cant get my breakpoints to hit on load. Im using 'inline-source-map'

I've tried with every devtool variant in Firefox Developer Edition and none of them seem to work. They all seem to work fine on Chrome and Safari (believe) though.
I think this might be an issue with the way Firefox parses source maps as opposed to how webpack outputs them.

I'm seeing issues as well - tried every config combo I can think of to generate full production source maps, but when I trigger errors they always point to the wrong location in the original source.
module.exports = {
  // ...
  devtool: 'source-map,
  plugins: [
    new UglifyJSPlugin({ sourceMap: true }),
  ],
  // ...
};

I've tried different things like using SourceMapDevToolPlugin, Babili instead of uglify, and limiting my app entry points to just 1, but nothing seems to work...
When I generate an error, the original source shows up fine in the Chrome inspector, but the error points to the completely wrong location in my src
Versions:
webpack: 2.2.1
babel-loader: 6.4.0
uglifyjs-webpack-plugin: 0.3.0
uglify-js: 2.8.7

EDIT: Upgrading from webpack 2.2.1 to 2.3.1 fixed the issue above for me!

@icd2k3 So, every devtool works correctly now?

@ibufu I've only tried it with source-map - definitely fixes the issues I was seeing with that (incorrect line/location mapping)

Just migrated to webpack 2. I'm using 2.3.2... same problem. sourcemaps still get wrong line mapping. I've tryed all of the above configs with no luck.

well, using #source-map instead of source-map did it for me so far...

@m--c Can you clarify where and how you're using #source-map instead of source-map?

The #source-map works well for me, please mark sure you webpack-dev-server command dont't include -d param, or devtool config won't take effect.
package.json
{
    "scripts": {
        "dev": "webpack-dev-server -d --inline --hot --env.dev"
    }
}

Once I remove -d param, it worked well.
{
    "scripts": {
        "dev": "webpack-dev-server --inline --hot --env.dev"
    }
}

I found it interesting that there are so many people subscribed to this issue, but it is behind “nice to have” features like “New Analyze Tool” or “Upgrade Code Style” on the voting website. Yes, you can vote for what features Webpack team spends its time on. If you care about this, let the team know. 😉
https://webpack.js.org/vote/

I just conducted a little experiment, which might be of interest here.
Chrome 57, webpack 2.3.3, babel-core 6.24.1, babel-loader 6.4.1, vue-loader 11.3.4

Line numbers
File names
File names mappable
Breakpoints
Proper breakpoints
Breakpoints trigger

No source maps
Refer to the bundle
:white_check_mark:
:white_check_mark:
:white_check_mark:

evalcheap-source-map
:x:
:white_check_mark:
:x:
:white_check_mark:
:white_check_mark:
:white_check_mark:

cheap-eval-source-map
:x:
:white_check_mark:
:x:
:white_check_mark:
:white_check_mark:
:x:

cheap-module-eval-source-map
:white_check_mark:
:white_check_mark:
:x:
:white_check_mark:
:white_check_mark:
:x:

cheap-module-source-map :tada:
:white_check_mark:
:white_check_mark:
:white_check_mark:
:white_check_mark:
:white_check_mark:
:white_check_mark:

eval-source-map
:white_check_mark:
:white_check_mark:
:x:
:white_check_mark:
:x:
:x:

source-map
:white_check_mark:
:white_check_mark:
:white_check_mark:
:white_check_mark:
:x: 1
:white_check_mark: 1

nosources-source-map
:white_check_mark: 2
:white_check_mark: 2
:white_check_mark:
:x:
:x:
:x:

inline-source-map :small_red_triangle:
:white_check_mark:
:white_check_mark:
:white_check_mark:
:white_check_mark:
:x: 1
:white_check_mark: 1

Notes:

Line numbers = whether the line numbers are correct
File names = whether the file names are correct
File names mappable = Sometimes the correct file name is shown, but with a suffix (foo.js?a1b2:123). In this case Chrome cannot map the file to the filesystem so it cannot be edited in the Developer Tools. Note: Currently, when I set up a mapping, I can no longer use breakpoints, I haven't found out the reason yet.
Breakpoints = whether breakpoints can be set at all
Proper breakpoints = sometimes breakpoints can be set, but only in certain lines, then this is marked false
Breakpoints trigger = whether the set breakpoints actually trigger

1 Breakpoints cannot be set properly, but set breakpoints do trigger.
2 Of course the source only shows after the file has been mapped, but then line number and file name are shown correctly.
:small_red_triangle: The inline-source-map style is not listed in this table.

@AndreKR, wow, awesome work! Would you (or anyone else) like to contribute this to our devtool documentation? We very often get requests to improve the devtool docs, but the truth is nobody exactly knows the in and outs. Until now :). It would be a shame if people never saw this table 😄.

Sometimes the correct file name is shown, but with a suffix (foo.js?a1b2:123)

Can the named modules plugin fix this issue? Have you tried it?
Kinda sucks that there are so many options for devtool without clear explanation of what's what. So better documentation, or even reducing these number of options could be great.

@SpaceK33z My table essentially lists what does not work. I feel like before we make those shortcomings a documented feature, someone should have a look and possibly fix some of them? Some of those might even be Chrome issues instead of Webpack issues.
In the meantime we should maybe just add a sentence like "For an overview of currently supported features for each source mapping style see this GitHub comment."

@AndreKR can you publish the source to the code you ran the tests under?
Can you also convert these to automated tests using chrome --headless and the debug websocket?

@graingert I could probably extract a minimal test case, yes.
About automated tests: I am familiar with automating a browser tab with chromedriver, but for automating the Developer Tools, I have no idea where to even start. I actually thought remote control via webdriver and  Developer Tools were mutually exclusive, because they use the same protocol.

Could you add tests for other browsers too?

I'd be curious how cheap-module-inline-source-map compares to those in the table?

@jgerigmeyer Oh, missed one - table updated. Spoilers: It works the same as cheap-module-source-map :tada:.

If cheap-module-source-map & cheap-module-inline-source-map produce the same quality, is there a performance difference? Since cheap-module-inline-source-map is missing from the table here, I can't tell.

cheap-module-source-map will be a bit faster for the browser to load
because it makes the source map optional
On 25 Apr 2017 8:31 am, "Jörn Zaefferer"<EMAIL_ADDRESS>wrote:

If cheap-module-source-map & cheap-module-inline-source-map produce the
same quality, is there a performance difference? Since
cheap-module-inline-source-map is missing from the table here
https://webpack.js.org/configuration/devtool/#devtool, I can't tell.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/webpack/webpack/issues/2145#issuecomment-296941444,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZQTAfF93Ep3_ziqT0GjSLSzy-qnPVkks5rzaFngaJpZM4HqOxx
.

Okay, that makes sense, but I'm more worried about the effect on (re)build times (that's what the linked table highlights). Any idea about those?

If they're significantly different, it would be a bug. Because it's
generating the same bytes just putting them somewhere different at the
final stage
On 25 Apr 2017 9:21 am, "Jörn Zaefferer"<EMAIL_ADDRESS>wrote:

Okay, that makes sense, but I'm more worried about the effect on (re)build
times (that's what the linked table highlights). Any idea about those?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/webpack/webpack/issues/2145#issuecomment-296956506,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZQTBcKrIZscBsZNYHuleDpNnppuBiKks5rza0ggaJpZM4HqOxx
.

Funny,
cheap-module-source-map works in FF, but doesn't work in Chrome
cheap-module-inline-source-map doesn't work in FF, but does work in Chrome
😭

Has anyone successfully mapped the source map files with filesystem folders using Chrome v60?
http://prntscr.com/f9yvgh http://prntscr.com/f9yvig
Chrome just doesn't map them.

@kurtextrem i did. The reason it didnt work inmy case is cause moduleFilenameTemplate option of
SourceMapDevToolPlugin was set to  "webpack:///[resourcePath]?[loaders]". Now because loaders doesnt include the ones from the config, but just tthe ones you specifically pass in your require, its usually the empy string, so you end up with stuff like  "webpack:///path/to/foo.js?". Chrome dev tools doesnt like that ? symbol on the end. What i did was instead of passing a string with placeholders, i passed a function which constructs the path, avoiding the trailing ?. The API allows you to pass a function for moduleFilenameTemplate.

@MagicDuck I'm doing this already:
devtoolModuleFilenameTemplate: info =>webpack:///${info.resourcePath}``
Also using cheap-module-source-map. Inline doesn't work either.

fyi. "breakpoints not triggering in eval-xxx-source-map" is a browser bug. It's reported here:
https://bugs.chromium.org/p/chromium/issues/detail?id=459499#c22
https://twitter.com/wSokra/status/869490447298723840

Note that the chromium bug can be starred for visibility - I've done so and encourage others to do so as well :)

As a workaround download latest chromium build for development
https://www.chromium.org/getting-involved/download-chromium

Thanks to you, I'm finally able to have my sourcemaps on Firefox!
devtool: 'cheap-module-inline-source-map',

or

devtool: 'cheap-module-source-map',

I just wonder now which one has the best performance.

@klimashkin it seems to work on firefox nightly, both. :)

Looks like eval sourcemaps might have been fixed in webpack fairly recently :)
https://github.com/webpack/webpack/blob/master/lib/EvalSourceMapDevToolModuleTemplatePlugin.js#L65
(based on workaround here I suppose: https://bugs.chromium.org/p/chromium/issues/detail?id=459499#c23)
I just copy pasted that line into my local node_modules/../EvalSourceMapDevToolModuleTemplatePlugin.js and it worked!!!

Is this still a known problem with Chrome and the latest webpack (3.3.0)? I have devtool set to 'cheap-module-inline-source-map' and I'm seeing issues (Chrome 59.0.3071.115 on OSX Sierra).

Since webpack 3 my source maps doesn't work as well 😕

FWIW, I was having this same issue. Deleted my node_modules folder and ran npm install and they started working.

I do that almost every day and it did not work. I tried almost all devtool options like source-map, cheap-eval-source-map or inline-source-map. None of them works at my machine.

Hooray! With the latest Chrome 60 it works again! 🎉 💃 😎

@screendriver
Which versions were you using. Now that I'm @ Microsoft on the EdgeDevTools team I'd like to work with Paul Irish and the rest of the Chrome Dev Tools folks and make sure we stay in sync if possible.

Now that I'm @ Microsoft on the EdgeDevTools team

I read that on Twitter. Congratulations! 🎉 😉
Currently I have following versions:
webpack: 3.4.1
TypeScript: 2.4.2
ts-loader: 2.3.2
Node: v8.1.0
Chrome: 60.0.3112.78

I'm still seeing issues with the following setup:
webpack: 3.4.1 (devtool set to inline-source-map)
Node: v6.9.5
Chrome:60.3.3112.78
I suppose I should try Node v8.1.0 although in theory should the node version matter?

AFAIK the node version shouldn't matter - I think it's really the Chrome / webpack versions that have bearing.

After upgrading to webpack 3 I also experienced problems. This combination works for me now:
Chrome: 60.0.3112.78
webpack: 3.4.1 with cheap-module-source-map

Had the same issue, but it was fixed by reinstalling node_modules.

My sourcemaps are working properly in Firefox, but not in Chrome. I'm gonna assume this an issue with Chrome. I'm on 60.0.3112.101 (Official Build) (64-bit).

Same here with the latest Vivaldi 1.11.917.39 (It uses Chromium 60.0.3112.91 with JavaScript V8 6.0.286.52 under the hood)

Has anyone found a workaround? I tried deleting node_modules and re-installing, but no luck. I've tried various different options for devtool and get the same warning on all of them.
Node: 8.3.0
Webpack: 3.5.5
Chrome: 60.0.3112.101

Anyone tried the betas?
On 22 Aug 2017 22:02, "James Simpson"<EMAIL_ADDRESS>wrote:

Has anyone found a workaround? I tried deleting node_modules and
re-installing, but no luck. I've tried various different options for
devtool and get the same warning on all of them.
Node: 8.3.0
Webpack: 3.5.5
Chrome: 60.0.3112.101
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/webpack/webpack/issues/2145#issuecomment-324150628,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZQTHju2S6SKjQk0FRw8cvUrPrSGleJks5sa0HYgaJpZM4HqOxx
.

People still having issues -- have you ensured you have Enable JavaScript source maps checked in your settings? For some reason unclear to me, this setting became unchecked recently. It's a once-and-done sort of thing, so I forgot about it's existence.

@petermikitsh Yes, source maps are enabled in my dev tools.

With the latest Vivaldi 1.11.917.43 that was released yesterday it's working again 😳 It is based on JavaScript V8 6.0.286.54 and Chromium 60.0.3112.105 (I'm using inline-source-map)

After pulling my hair for 2hs I got it working on
webpack: 3.5.5
Javascript ES6
Node: v8.2.1
Chrome: 60.0.3112.101
(symfony encore 0.14)
using devtool: 'cheap-module-eval-source-map'

Anyone got this to play nicely with vscode chrome debbuger
At this rate, i'll be bald by the end of the day

inline-source-map only works in Chrome (60.0.3112.113) the first time page loaded. Works well in FireFox and Chrome Canary.
eval-cheap-module-source-map  works fine in all three browsers, but disabled adding breakpoints.
I did some further tests, It looks like eval-*** options will always work, but disabled adding breakpoints, while others only works the first time when page loaded in Chrome.
To me, it more likes a Chrome bug, because it is solved in Canary. I would use inline-source-map at this point, and use ALT + R to refresh the dev tool in Chrome to make the source map works.

I am still having issues with this one. What is the status of it?

Have this problem too i Chrome.
Works fine in Firefox.
Restarting webpack caused Chrome to update so I suspect it is some error there that Firefox detects and Chrome does not.

+1

This does not work for me in Chrome 62, regardless of what I set devtool as.
I can verify that the .map files are indeed being generated and have the proper names (they are also properly referenced from the JS files they belong to), but when I try to open the files in DevTools, nothing gets loaded.
It's been a while since I last visited this issue, but I am almost certain it kind of worked for med in Chrome 57.

+1
Chrome 62, High Sierra

Same issue Version 55.0.2883.87 Built on Ubuntu , running on Ubuntu 16.04 (64-bit)

Why is this closed? It is clearly still an issue.

@csvan I know how you feel, I still think Chrome devtools is the best available.
My bug report was recently updated to WontFix saying "This is a known issue with webpack; we can't do much" because "Webpack changes the content of the sourcemaps resources"
It would seem that Chrome has indicated that the fault is solely with Webpack, but I feel that a solution would not be that difficult (esp. if a dev was fluent in WDS & chrome devtools internals). //cc @aslushnikov @pavelfeldman

Sourcemaps and browsers together are really weird.
For instance, the only sourcemap which works on both browsers (firefox and chrome) is cheap-module-inline-source-map
But this is for webpack itself.
About babel/js now, the sourcemap works also well on both browsers.
However, for css-loader for instance, sourcemap doesn't work at all on firefox but does on chrome.
It's like tennis table here. :')

@jakeNiemiec the issue you're pointing to is about the DevTools Workspaces automapping against sourcemapped files. AFAIU it's not related to the issue discussed here, or am I missing something?

@aslushnikov I was trying to make the point that the Workspaces 2 chrome feature that was added for everyone in Chrome 63 breaks Webpack sourcemaps. Now it seems that the issue is affecting other webpack devs
It would have been nice to have the option to opt-out of this breaking change.
(I may be wrong, but I believe that Workspaces 2 is the former Persistence 2 experiment)

Just throwing some tips for people on Chrome with issues.
If you have the original files, you don't want to use to include the source code in your source map. Use nosources-source-map so that the source map only includes weak references to files and lines. Then Chrome will map that to your workspace files. If you include sources, then you're essentially telling Chrome to look in webpack://* for the sources instead.
It would be nice if you could remap webpack:// to your project folder, but Chrome removed this functionality. If you are using Visual Studio Code with the popular Chrome debugging plug-in, be sure to create a workspace remapping.

This is very much still an issue.

This issue was confirmed as intentional by @ChromeDevTools in this thread: https://twitter.com/dan_abramov/status/960324134734573569
There's a lot of talk, but this was the best I could get out of them:

Ah, I see. Yeah, at the moment the explicit mappings are gone from Workspaces 2. I'm hearing a lot of feedback similar to yours, though, and we're exploring our options --- kayce

There's 130 people subscribed to this thread, I think this issue could use a bit more visibility. I really don't like to see Chrome enforcing certain user/dev workflows like this.

There is a workaround in the second post on this thread:
https://github.com/webpack/webpack/issues/6400

The amount of time I've spent since the first npm i -D webpack is unacceptable, and much more than the time I actually spent developing web applications.
So it's not just me who thinks webpack is awefully bloated. Good to know. Thanks for saving me all these hours!

Configuring with this devtool: 'inline-module-source-map' into webpack fixed my issues where debugger wasn't acessing the current context

inline source maps works

Configuring with this devtool: 'inline-module-source-map' into webpack fixed my issues where debugger wasn't acessing the current context.
I'm running with webpack-dev-server and webpack 4

this solution worked for me. Thanks @wallynm

This is not working anymore on wepback 5. No matter what type I use, I won't get to see the original code.