Plan for 8.x-3.0-alpha1 release

@dman
You make some valid points here. You are probably right that developing a generic Tamper module first will slow down the progress for Feeds D8. So that is a valid concern for dropping Tamper module for now.
Good to hear also that there already other tools available that provide similar functionality. It would be good to investigate what they are and if it wouldn't take a lot of effort to depend on them. If it does seem to take a lot of effort, we should just go for a more 'simple' port of Feeds Tamper for now.
@dman, would you like to check what these other tools were? I know there is a Typed data API, which I haven't studied yet. Can it be that these tools are somewhere inside that API?

@dman, @ericgsmith
I appreciate sharing your thoughts on this subject. Not sure if understood everything of it exactly, but I'll try to respond it by my best knowledge.

Tamper with fields via event subscribers

There is already a parse event, which I had in my mind of using for Feeds Tamper. If you add a listener to this event with a lower priority than Feeds does, you'll get the parsed result which you then can modify:

class FeedsTamper implements EventSubscriberInterface {
  /**
   * {@inheritdoc}
   */
  static function getSubscribedEvents() {
    $events[FeedsEvents::PARSE][] = ['afterParse', -100];
    return $events;
  }

  /**
   * Act on parser result.
   */
  public function afterParse(ParseEvent $event) {
    /** @var \Drupal\feeds\FeedInterface */
    $feed_type = $event->getFeed();
    /** @var \Drupal\feeds\Result\ParserResultInterface */
    $parser_result = $event->getParserResult();

    /** @var \Drupal\feeds\Feeds\Item\ItemInterface */
    foreach ($parser_result as $item) {
      // Example: get an item's value.
      $authors = $item->get('authors');
      // Manipulate value.
      // 'authors' is for example: 'Morticia,Fester,Gomez'.
      $authors = explode(',', $authors);
      // And set an item's value.
      // 'authors' is now: [
      //   'Morticia',
      //   'Fester','
      //   'Gomez',
      // ].
      $item->set('authors', $authors);
    }
  }
}

I don't think that we need another event layer in this process. I do notice that there is a difference with MigratePreRowSaveEvent: in there, there's an event per row, while in the above example there is one event for all rows (or at least the rows that have been parsed which can happen in chunks, for CSV say 50 records per cycle). I'm not sure if it is bad to have an event for multiple rows instead of an event per row.

Even if Feeds and Feeds_Tamper is still part of the same project, it's ok for the one module to respond to its own events.
*This*, I feel, provides the abstraction of a 'tamper' opportunity that the proposed 'Tamper' module was envisioning, without introducing additional dependency or layers.

I'm not sure if I quite understand this. What I can tell is that Feeds already responds to its own events for performing its core tasks (fetching, parsing, processing). It sounds like you are proposing that each Tamper plugin should respond to an event. I had in mind the use of a FeedsTamperPluginManager which - based on the FeedsType - checks which Tamper plugins are configured for that type. Each configured Tamper plugin will have a weight in Feeds Tamper, which the plugin manager uses to sort the plugins so they run in the right order. On the parse event, the plugin manager would then loop through all the rows and apply all configured Tamper plugins on each row.

Typed Data as internal row format

I haven't quite got into Rules for D8 yet, but it sounds like a good idea to have Rules events for each Feeds event and that you can work with the data within Rules. When responding to the parse event in Rules, Rules would see how each item is expected to look like.
This feature does seem like a nice to have at the moment though, so I think that we should schedule it for after the first alpha release of Feeds.

Decoupled Tamper module

@ericgsmith, Great for working out a 'playground' of the Tamper module. It looks already way more advanced than my initial playground. While a separate Tamper module could add additional time to develop and probably adds extra complexity (because more modules will be in play), I think we should give it a go, certainly because ericgsmith's playground looks like to head in a good direction. If, after a while, it doesn't seem to work out, we can then still go for a more straightforward port of Feeds Tamper.

I propose to check back after a few weeks to see if the Tamper module evolves further and if Feeds Tamper can make use of the Tamper plugins. Let's aim to have steps 1 until 3 from #2917926: Port Feeds Tamper to D8 be done by December 31, 2017. That is:

1. Develop generic Tamper module architecture with at least one working Tamper plugin (but preferable a few more).
2. Let Feeds Tamper make use of Tamper plugins and apply these on the parser result (bridge between Tamper and Feeds).
3. A config schema for Feeds Tamper (each instantiated plugin needs at least a reference to the feed type, a reference to the source field and a weight).

Would that fit into your schedule, @ericgsmith? If so, I'll plan a few hours a week to work on the code for this as well.

Perhaps we should move the discussion about Tamper over to #2917926: Port Feeds Tamper to D8 as I had there a separate discussion about it with @larowlan.

@DamienMcKenna
Thanks for asking!

Strictly spoken, the Tamper module isn't needed for the first alpha as there are possible workarounds. In my opinion though these workarounds are not obvious and therefore hard to apply for non-developers.

My idea of the first alpha release is to have a Feeds version that covers at least basic usage without custom coding. In my opinion at least the Tamper plugin "explode" (with which you can turn a value into multiple values) belongs to the basic use cases. It is often needed when importing CSV files where you can put a list of values into a single column.

I've updated the links to issues in the issue summary. For the UI of Feeds Tamper an issue has been created #2937728: Add an UI. Development on the Tamper module can be tracked on #2921727: Full release of Tamper, though #2917926: Port Feeds Tamper to D8 currently contains most of the discussion on the module.

An UI for the CSV parser is added!

Two followup issues have been created:
#2938505: Add UI for editing and removing custom (CSV) sources
#2938500: Add UI tests for the CSV parser

Both should be aimed for, but they are not blockers for 8.x-3.0-alpha1.

Added #2857692: Update existing nodes fails when not mapping to "Feeds Item: Item URL": This value should be of the correct primitive type. as a target for the first alpha release.

This week in Feeds D8:

1. Max completed implementing permissions for Feeds Tamper: #2942067: Implement permissions. He'll be working on the Feeds Tamper UI next.
2. Eric worked on a Feeds Tamper add form (in order to test Tamper config forms better): #2937728: Add an UI.
3. Eric made some progress on the Tamper module: #2937719: Multiple value handling, #2937721: Create 'SkipException' classes. and #2937717: Add support for manipulating a complete 'feeds item'/'row'..
4. MegaChriz made #2939503: Unpublish/Delete nodes not included in feed ready for review/testing. He also added some automated tests to Feeds.

Next Feeds meeting will be on Thursday, February 15 at 19:00 UTC on Drupal Slack in the #feeds channel!

This week in Feeds D8:

1. Errors with feeds_item.0.url were fixed! #2857692: Update existing nodes fails when not mapping to "Feeds Item: Item URL": This value should be of the correct primitive type.
2. Unpublish/delete nodes not included in feed was finalized! #2939503: Unpublish/Delete nodes not included in feed
3. Feeds has a more usable base class for functional tests.
4. Better handling of multiple values in Tamper plugins: #2937719: Multiple value handling and #2948569: Handle multival changes from tamper module

The plan for the coming week:

1. Finalize remove Tamper UI: #2948850: Add an availability to remove tampers from sources
2. Fix #2946698: Call to undefined method getSetting() in all tampers together with #2948543: Make all plugins configurable
3. Max plans to finish the Feeds Tamper overview page (the UI where you can see all plugins on the Feed type with links to add, edit and delete). #2937728: Add an UI
4. Eric plans to look further into using context aware Tamper plugins: #2937717: Add support for manipulating a complete 'feeds item'/'row'.
5. The XML parser UI: MegaChriz plans to examine what changes would be needed to both Feeds and Feeds extensible parsers to supply the "context" field at the top of the mapping page. #2917924: Implement the XML Xpath parser UI
6. Should there be time left, MegaChriz plans to review/test #2911491: Provide feeds type fields as mapping sources

Added references for follow-ups for the Feeds Tamper UI in the issue summary: #2953361: Allow Tamper plugins to be reordered and #2953362: Allow Tamper plugins to be enabled/disabled.

This week in Feeds D8:

1. The UI for removing Tampers was finalized: #2948850: Add an availability to remove tampers from sources
2. Max made the UI for the Tamper listing: #2937728: Add an UI. For the UI listing there are three follow-ups: #2953361: Allow Tamper plugins to be reordered, #2953362: Allow Tamper plugins to be enabled/disabled and #2949203: Add UI tests.
3. Irina worked on a plan for Feeds + Migrate integration: https://docs.google.com/document/d/1XJpw36kw-Fpck_kLa9iR8wEtKInhz9SxgZ1F...

The plan for the coming week:

1. Irina will continue to work on the Feeds + Migrate integration plan.
2. The XML parser UI: MegaChriz plans to examine what changes would be needed to both Feeds and Feeds extensible parsers to supply the "context" field at the top of the mapping page. #2917924: Implement the XML Xpath parser UI
3. Should there be time left, MegaChriz plans to review/test #2911491: Provide feeds type fields as mapping sources

This week in Feeds:

1. A start was made on the XML Xpath parser UI: #2917924: Implement the XML Xpath parser UI
2. Fixes for #2948543: Make all plugins configurable and #2946698: Call to undefined method getSetting() in all tampers were committed.

The plan for the coming week:

1. Irina will continue to work on the Feeds + Migrate integration plan.
2. MegaChriz plans to work further on the XML Xpath parser UI.
3. Eric plans to work further on #2937721: Create 'SkipException' classes..

The next Feeds meetup will be on Thursday, March 29 at 18:00 UTC. That's one hour earlier as before. The time shift happens because of daylight saving time in Europe. So in Europe time, it will be at the same time.

@cmcintosh
Other content entity types can be supported as well. I have been experimenting with a wider support of content entity types in my sandbox module Feeds DEV. So far, that particular feature - a generic entity processor - seems to work very well. I have only tested it on Commerce products and Commerce product variations though.

Feeds 8.x-3.0-alpha1 has been released! Feeds extensible parsers 8.x-1.0-alpha1 has been released as well.

I'll update this issue when an initial plan for the next release is made.

8.x-3.0-alpha2 has been released!
https://www.drupal.org/project/feeds/releases/8.x-3.0-alpha2

See what is planned for the next release: #2978642: Plan for 8.x-3.0-alpha3 release.